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1.  OVERVIEW 

The  goal  of  the  microcode  verification  project  at  ISI  Is  to  develop  both  the  theory  and 
the  tools  for  verification  of  microcode  While  some  prior  work  has  been  done  In  this 
area,  notably  [Patterson  77,  Birman  &  Joyner  76],  the  field  was  (and  Is)  far  from  closed. 
Problems  exist  at  every  level,  from  fundamental  questions  of  theory  through  questions  of 
strategies  of  system  design  to  problems  of  Integration  with  other  software  engineering 
tools  and  education  of  users.  Our  strategy  has  been  to  concentrate  on  developing  a 
working  system,  letting  the  theoretical  Issues  emerge— sometimes  painfully — amid 
system  development.  We  have  tried  to  delay  overall  consideration  of  the  human 
engineering  questions,  but  have  been  forced  to  consider  some  of  these  when  It  became 
too  difficult  to  use  our  own  system  without  Improving  the  Interface. 

To  establish  a  focus  for  the  project  and  provide  a  source  of  examples,  we  selected  a 
particular  computer,  the  Fault-Tolerant  Spaceborne  Computer  (FTSC),  under  development 
by  Raytheon  for  the  Space  and  Missile  Systems  Organization  (SAMSO)  of  the  Air  Force. 
The  FTSC  has  a  number  of  unusual  features  related  to  Its  design  goal  for  a  five-year 
maintenance-free  survival  In  space.  These  features  appear  primarily  at  the  hardware 
level  and  In  the  operating  system,  however,  not  In  the  architecture  seen  or  Implemented 
by  the  microcode.  At  the  machine  language  level,  the  programmer  sees  a  32-blt  machine 
with  04K  of  memory,  8  general  purpose  registers  and  the  usual  types  of  Instructions.  At 
the  microcode  level,  the  machine  Is  horizontally  microprogrammed  with  78-blt  Instructions 
decoded  Into  37  different  fields.  (As  of  this  writing,  the  machine  has  been  redesigned 
to  have  a  shorter  microinstruction.  We  have  not  token  these  changes  Into  account  In 
the  present  work,  but  will  focus  on  the  new  design  In  the  next  effort.)  Documentation  of 
the  FTSC  Is  given  In  [Raytheon  Corp  79]. 

The  key  criterion  for  selecting  the  FTSC  Is  that  it  Is  a  real  machine  developed  outside 
our  control.  We  believe  that  It  Is  possible  to  verify  code  for  nearly  arbitrary  machines, 
Irrespective  of  the  techniques  used  to  develop  the  code.  This  view  differs  somewhat 
from  those  of  other  verification  researchers,  notably  [London  77].  To  be  fair,  It  Is  quite 
clear  that  much  of  the  labor  In  the  verification  task  can  be  reduced  If  verification  and 
code  development  are  carried  out  together  and  If  the  strategies,  practices,  and  tools 
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used  to  develop  the  code  are  also  geared  toward  verification.  But  we  view  this  as  a 
secondary  concern  and  not  fundamental  to  the  verification  task.  In  a  moment,  we  will 
mention  where  the  savings  In  labor  would  occur. 

We  view  a  microprogram  verification  system  In  the  following  terms.  A  user  prepares 
formal  descriptions  of  the  host  machine  and  the  target  Instruction  set.  He  also  obtains 
a  copy  of  the  microcode  that  runs  on  the  host  machine  and  allegedly  Implements  the 
target  Instruction  set.  He  then  prepares  a  proof  that  the  microcode  does  Indeed  behave 
as  desired,  end  submits  all  four  of  these  files— host  description,  microcode,  target 
description,  proof— to  the  verification  system,  which  then  examines  the  target 
description  to  determine  all  aspects  of  Its  behavior  needing  implementation,  for  eaoh 
sequence  of  events  that  must  be  Implemonted,  the  system  symbolically  executes  the 
microcode  according  to  the  rules  of  the  host  machine  and  demonstrates  that  the 
required  sequence  of  events  does  take  place. 

No  system  can  be  quite  smart  enough  to  carry  out  all  possible  demonstrations  completely 
automatically,  so  some  help  may  be  needed.  Some  systems  operate  on  the  principle  that 
the  system  should  try  very  hard  to  succeed  on  Its  own  and  then  ask  for  help  after  It  has 
tried  all  possible  heuristics.  While  this  approach  seems  attractive,  It  has  a  fundamental 
drawback.  When  the  system  asks  the  user  for  help,  the  user  Is  generally  unaware  of 
what  the  system  already  has  tried  to  do,  what  level  of  detail  Is  needed,  or  even  what 
problem  the  system  Is  working  on.  The  underlying  difficulty  Is  that  the  user  must  have 
some  Idea  of  how  the  system  Is  constructed  and  understand  how  to  drive  the  system. 
At  the  same  time,  we  note  that  the  system  Is  really  trying  to  formally  document  the 
rationale  for  each  Instruction  In  the  microprogram.  However,  this  Is  Just  what  the 
programmer  had  to  do  himself  when  ho  wrote  the  program.  Combining  these  two 
observations,  we  have  taken  the  view  that  the  verification  system  should  be  driven  by 
the  user,  not  the  other  way  around.  The  user  should  have  a  complete  understanding  of 
what  the  verification  system  will  and  will  not  do,  and  the  user  should  drive  the 
verification  system  toward  believing  tho  correctness  of  the  code.  In  this  view, 
Interaction  between  the  system  and  the  user  takes  the  form  of  a  prepared  proof,  and  It 
becomes  meaningful  to  ask  what  Is  the  proper  language  for  writing  proofs.  Wegbrelt's 
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paper  [Wegbrelt  77]  explores  this  area  elegantly  for  well- structured  algorithmic 
languages.  For  microcode  generated  with  minimal  assembly  language  tools,  different 
engineering  Is  required,  but  the  basic  Idea  is  the  same.  At  the  present  time,  our  "proof 
language"  Is  nothing  more  than  a  set  of  commands  to  the  proofchecker.  However,  as  we 
gain  experience  with  the  system,  It  becomes  clear  how  to  structure  these  commands 
Into  phrases;  thus  the  development  of  a  proof  language  begins.  At  the  same  time,  It  is 
worthwhile  to  ask  whether  the  production  of  both  the  microcode  and  the  proof  of  Its 
correctness  can  share  any  tools.  The  answer  must  be  "yes,"  but  we  have  not  yet 
considered  any  specific  Implementation. 

Although  we  wish  our  system  to  be  as  general  and  as  useful  as  possible,  our  present 
design  horizons  embody  the  following  limitations: 

-  The  purpose  of  the  microcode  must  be  to  Implement  the  Instruction  set  of  a 
computer.  This  restriction  Is  Intended  to  limit  the  difficulty  of  specifying 
the  Intended  behavior  of  the  microcode.  With  this  restriction,  we  rule  out 
microcode  that  Is  just  arbitrary  lower  level  code  to  Implement,  say, 
operating  systems,  signal  processing  algorithms,  device  controllers,  etc. 

This  restriction  Is  not  really  fundamental  to  our  work  and,  as  we  shall  see, 
does  not  quite  guarantee  that  we  shall  always  have  a  straightforward  way 
to  specify  the  Intended  behavior  of  the  machine. 

-  Since  we  do  not  yet  have  sufficient  tools  to  represent  or  reason  about 
concurrency  or  time-dependent  behavior,  we  demand  that  our  microcode 
be  written  for  a  sequential  machine  and  that  It  implement  the  Instruction 
set  of  a  sequential  machine. 

-  We  intend  that  the  result  of  this  research  be  a  demonstrable  system  with 
the  real  possibility  that  someone  other  than  ourselves  should  be  able  to 
formulate  a  task  and  carry  It  out.  We  do  not  intend,  however,  that  the 
system  be  efficient,  completely  robust,  smoothly  human-engineered,  or 
thoroughly  documented.  Users  of  the  system  should  understand  the  state 
of  development.  Their  success  rate  will  be  higher  If  they  communicate  with 
us  before  and  during  any  experimentation. 

In  addition  to  the  caveats  above,  tho  system  we  are  building  Is  not  yet  ready  for 
release. 
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Carrying  out  a  complete  proof  may  be  fairly  tedious.  Preparation  of  the  formal 
descriptions  often  appears  to  be  a  stralghforward  task  of  encoding  the  Information  In 
the  manuals  that  accompany  the  machine,  but  we  have  noticed  that  many  Important 
details  are  often  omitted  from  such  documents,  and  others  are  misdocumented. 

Programmers  developing  the  mlcrocodn  come  to  understand  these  details  and  use  their 
knowledge  to  write  or  debug  their  code.  If  the  person  writing  the  formal  description  Is 
not  similarly  steeped  In  the  culture  of  the  machine  under  consideration,  a  similar  learning 
period  will  be  required. 

Writing  the  proof  may  be  tedious,  for  three  reasons.  First,  a  complete  understanding  of 
the  code  Is  necessary.  The  programmer  understands  the  code;  the  person  responsible 
for  verification  may  not.  A  period  of  study  may  be  necessary  before  any  of  the  proof 
can  be  written.  Of  course,  If  the  programmer  were  also  responsible  for  preparation  of 
the  proof,  then  the  verification  would  proceed  all  the  faster.  Unfortunately,  with 
verification  still  In  the  research  phase,  programmers  who  build  "real"  programs  are  far 
too  busy  to  spend  the  extra  time  required  for  verification.  Also,  since  verification 
requires  some  special  knowledge,  production  programmers  may  not  be  skilled  In  the  art 
of  preparing  formal  descriptions  and  proofs. 

The  second  difficulty  Is  that  the  code  may  be  relatively  complicated  to  verify.  At  the 
beginning  we  Insisted  that  It  should  be  possible  to  verify  code  even  if  It  were  written 
without  knowledge  that  it  would  be  subjected  to  verification.  (We're  assuming,  of 
course,  that  the  code  does  Indeed  work!)  However,  It  Is  equally  clear  that  there  are 
many  strategies  for  writing  code  and  that  some  of  them  may  be  equally  good  from  the 
programmer's  point  of  view  but  require  very  different  levels  of  effort  In  verification. 

The  third  difficulty  Is  that  proofs  may  be  tediously  long.  We  have  said  that  the  user 

must  drive  the  verification  system  with  a  proof  and  that  the  verification  system  must 

proceed  so  as  to  give  the  user  a  clear  idea  of  what  the  system  Is  doing.  However,  a 

trivial  way  to  build  such  a  system  Is  to  moke  It  extremely  simple,  with  the  result  that 

proofs  will  be  extremely  long  and  require  the  user  to  spend  a  long  time  preparing  them.  j 

In  the  extreme,  this  Is  not  permissible;  It  Is  necessary  to  build  the  system  with  enough 

knowledge  so  the  "straightforward"  deductions  are  carried  out  automatically.  There  Is 

no  possibility  that  any  system  can  know  a  "maximum"  of  knowledge,  for  there  will  always 
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be  problems  that  can  be  proven  with  a  system,  but  not  proven  automatically.  At  the 
same  time,  there  Is  no  limit  to  making  a  system  smarter;  we  can  always  go  beyond  the 
previous  limits  and  build  a  next  system  that  understands  more  than  the  last.  Clear 
measuros  of  the  smartness  of  one  system  compared  to  another  do  not  yet  exist,  but  It  Is 
a  question  that  Is  likely  to  gain  attention  ns  various  verification  systems  are  used  for 
larger  and  larqer  problems. 

As  we  said  earlier,  we  have  restricted  our  interest  to  microcode  that  implements  the 
Instruction  set  of  some  computer  The  intention  of  this  limitation  Is  to  make  It  easy  to 
specify  the  Intended  behavior.  Unfortunately,  this  restriction  does  not  quite  work.  In 
the  description  of  the  host  architecture,  vie  have  no  difficulty  In  formalizing  all  aspects 
of  concern,  excepting,  of  course,  timing  and  concurrency.  We  view  the  host  machine  as 
operating  on  bltstrlngs  of  finite  length  The  operators  for  bltstrings  are  concatenation 
and  selection,  logical  operations,  e  g.,  AMD,  OR  and  NOT,  and  the  simple  Integer  arithmetic 
operations.  At  the  target  level,  however,  we  have  not  been  so  fortunate.  Bltstrlngs 
remain  the  dominant  datatype,  and  all  of  the  bitstring  operators  are  still  required,  but 
new  operations  exist  that  are  not  simply  characterized  by  short  descriptions.  Floating 
point  arithmetic  Is  the  most  obvious  and  ettenslve  area,  but  some  machines  have  other 
Instructions  whose  behavior  Is  quite  difficult  to  characterize  In  terms  of  bltstrlngs.  Edit 
And  format  Instructions  provide  many  examples,  as  do  Instructions  that  find  the 
lowest-order  or  higher-order  1  bit. 

The  FTSC  computer  Is  blessed  with  the*  usual  complement  of  floating  point  Instructions; 
Indeed,  It  even  has  a  floating  point  square  root  instruction.  On  the  grounds  that  avoiding 
these  Instructions  would  trivialize  the  effort  and  leave  us  an  undetermined  distance  from 
realizing  a  system  capable  of  verifying  real  microprograms  for  real  machines,  we  decided 
to  tackle  the  floating  point  arithmetic  head  on. 

We  divided  the  specification  of  the  target  machine  into  two  levels.  The  first  Is  written 
In  the  same  terms  as  the  host  machine  description.  It  Is  restricted  to  simple  bitstring 
operators.  At  this  level,  the  simple  target  machine  instructions,  e.g.,  load,  store,  Integer 
add,  Jump,  etc.,  are  stated  as  succinctly  as  they  will  ever  be  stated  and  no  further  work 
Is  required.  The  floating  point  Instructions,  however,  look  like  short  but  complicated 
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algorithms  that  provide  an  explicit  view  of  how  the  words  are  divided  Into  a  mantissa 
and  exponent,  how  normalization  takes  place,  etc. 

For  these  Instructions,  we  provide  a  higher  level  of  specification  that  shows  that  the 
result  of  that  algorithmic  specification  has  certain  properties.  This  higher  level  of 
specification  requires  the  Introduction  of  the  reals,  and  the  properties  are  stated  In 
terms  of  the  Interpretation  of  the  floating  point  bltstrlngs  as  real  numbers.  For  example, 
the  desired  property  of  the  square  root  Instruction  Is  that  It  computes  the  largest 
floating  point  number  whose  square  Is  not  larger  than  the  original  number.  (The  notion  of 
"largest  floating  point  number"  requires  even  a  little  more;  the  granularity  of  the  floating 
point  numbers  is  also  an  Issue  ) 

In  the  work  to  date,  we  have  written  a  complete  specification  of  the  FTSC  at  both  the 
host  and  algorithmic  target  level,  but  we  have  not  defined  the  properties  required  of  the 
floating  point  Instructions  except  for  the  square  root  Instruction.  We  have  focused  on 
the  square  root  Instruction  simply  because  It  seemed  to  expose  all  of  the  Issues  likely 
to  come  up  In  any  other  Instruction. 

The  basic  plan  for  verifying  the  correctness  of  the  microcode  thus  has  two  parts.  One 
part  Is  to  verify  that  the  microcode  running  on  the  host  machine  Implements  the 
algorithmic  target  level.  The  second  part  Is  to  verify  that  the  algorithmic  target  level 
has  the  additional  properltles  desired. 

At  the  present  time,  we  have  completed  the  proof  that  the  algorithmic  target  description 
of  the  square  root  Instruction  has  the  desired  property.  We  have  not  yet  proven  similar 
properties  for  other  Instructions,  nor  have  we  proven  the  correspondence  between  the 
host  machine  and  the  target  Instruction  set,  for  the  FTSC.  We  have,  however,  created  a 
simple,  fictitious  machine  and  carried  out  a  complete  proof  of  the  correctness  of  Its 
microcode.  This  small  machine  Is  called  the  TOY  machine.  Both  of  these  proofs  are 
documented  In  chapter  four. 

Completion  of  proofs  Is  one  measure  of  progress,  but  there  Is  much  that  precedes  the 
ability  to  carry  out  proofs.  A  sound  theoretical  basis  must  exist  or  be  developed  and  a 
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functioning  proof  system  must  be  developed.  These  activities  have  conaumed  the 
majority  of  our  time  and  resources. 

In  chapter  two,  we  discuss  the  theoretical  basis  for  our  proof  system  and  introduce  the 
language  we  use  for  expressing  the  behavior  of  machines  and  the  properties  of 
programs.  In  chapter  three,  we  outline  the  structure  of  the  proof  system  and  give 
details  for  selected  components. 

This  work  Is  still  In  progress.  The  details  of  language,  structure  and  capabilities  are  all 
evolving. 
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2.  LANGUAGE  AND  THEORY 

In  this  chapter  we  discuss  the  formal  basis  of  and  the  language  we  have  choaen  for 
both  encoding  our  descriptions  of  machines  and  reasoning  about  the  course  of 
computations.  Internally,  our  notation  Is  chosen  for  Its  precision  and  ease  of  processing, 
qualities  that  contrast  with  the  desire  for  compactness  and  richness  In  the  languages 
read  and  written  by  humans.  Both  levels  exist,  and  there  must  be  translation  between 
them.  As  often  happens,  subtle  and  Important  Issues  emerge  In  the  translation.  At  IBM, 
the  difficulties  of  using  two  levels  of  language  have  been  avoided  by  dealgnlng  a 
special-purpose  language  that  Is  both  computationally  tractable  and  not  too  unwieldy  for 
humans.  That  language  Is  documented  in  [Joyner  et  al.  78]. 

ISPS 

To  represent  the  host  and  target  machines,  we  have  chosen  to  use  the  ISPS  language. 
ISPS,  a  derivative  of  Bell  and  Newell's  ISP  language  [Bell  and  Newell  71],  Is  now  In 
modest  use  by  a  number  of  organizations.  Documentation  of  the  current  version  Is  given 
In  [Barbaccl  et  al.  77];  the  examples  In  chapter  four  are  written  in  ISPS. 

Descriptions  of  machines  have  been  written  in  ISPS  for  a  number  of  different  purposes, 
Including  simulation,  architecture  evaluation,  documentation,  computer-aided  design,  and 
(In  variants  of  ISPS)  automatic  generation  of  code  generators  and  assemblers.  This 
variety  of  activity  associated  with  the  language  Is  useful  In  two  ways.  On  the  one  hand, 
the  use  by  large  numbers  of  people  Improves  the  possibility  that  a  standard  will  emerge, 
that  documentation  of  computers  will  bo  more  accurate  and  more  complete,  and  that  the 
task  of  preparing  formal  descriptions  of  the  host  and  target  levels  of  a  microprogrammed 
machine  will  be  carried  out  by  the  machine  designers  Instead  of  by  the  verification 
group. 

On  the  other  hand,  the  wide  variety  of  applications  using  ISPS,  each  with  Its  own 
software  to  process  ISPS  descriptions,  has  tended  to  expose  the  lack  of  a  precise 
semantics  for  the  language.  As  an  experiment  to  gain  some  leverage  on  the  semantics 
of  ISPS,  Pete  Alfvln  developed  a  denotatlonal  semantic  definition  of  AMDL,  an  abstract 
syntax  version  of  ISPS  In  use  at  ISI  [Alfvln  79]. 
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Aa  wo  mentioned  In  the  overview,  while  It  may  look  simple  to  encode  the  details  of  a 
machine's  Instruction  set  In  ISPS,  It  may  be  tedious  In  actuality.  In  the  case  of  the 
FTSC,  a  machine  under  development  and  redesign,  a  number  of  small  but  Important 
details  were  either  undocumented  or  mlsdocumented.  We  developed  simulation  tools  to 
execute  the  descriptions  we  wrote  and  used  the  simulations  to  execute  the  diagnostics 
for  the  machine  at  both  the  host  and  target  levels.  In  essence,  this  amounted  to  a 
"verification  by  testing"  approach;  since  the  microcode  itself  was  used  In  some  of  these 
tests,  It  Is  reasonable  to  ask  If  we  perturbed  the  description  of  the  machine  In  order  to 
make  the  code  work.  Stated  another  way,  how  do  we  know  that  the  description  of  the 
host  machine  Is  an  accurate  representation  of  how  the  hardware  really  works,  and  how 
do  we  know  that  the  description  of  the  target  machine  Is  an  accurate  representation  of 
how  the  target  machine  Is  supposed  to  work?  There  can  be  no  completely  satisfactory 
answers  to  these  questions.  The  descriptions  at  both  levels  must  be  accepted;  they 
cannot  be  checked  In  any  rigorous  sense  within  the  confines  of  the  microcode 
verification  paradigm.  If  there  exists  another  description  at  a  higher  or  lower  level,  then 
the  corresponding  descriptions  may  be  checked  against  It.  However,  this  merely  pushes 
the  problem  off  one  level,  and  there  Is  no  ultimate  exemption  from  a  requirement  to 
accept  the  bottom  level  description  as  the  way  the  machine  actually  works  and  the  top 
level  description  as  the  way  the  system  Is  supposed  to  work. 

Complete  assurance  having  been  denied  us,  we  can  ask  what  lesser  assurance  Is 
available.  By  using  a  language  understood  by  a  number  of  people  (In  particular  by  the 
designers  of  the  machine,  the  microprogrammers  of  the  machine,  and  the  programmers  at 
the  assembly  language  level)  we  can  have  some  hope  that  they  all  share  the  same 
understanding  of  the  machine  If  they  were  to  depend  upon  the  same  descriptions  as 
their  reference.  This  Is  not  yet  the  case  for  any  machine  with  any  description  system, 
but  we  see  no  reason  why  It  could  not  he. 

To  complete  our  discussion  of  ISPS,  wo  again  mention  that  ISPS  does  not  provide 
primitives  for  representing  floating  pe  *.  operations;  we  have  had  to  code  them  In  ISPS 
as  small  algorithms.  Since  the  lack  of  standard  notions  and  designs  of  floating  point 
arithmetic  Is  a  common  problem,  the  choice  of  another  language  would  not  have  Improved 


matters. 
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STATE  DELTAS 

In  order  to  build  a  proof  system,  a  formal  basis  for  reasoning  about  machines  Is  required. 
Ordinary  first-order  predicate  calculus  Is  often  used  as  a  foundation,  but  It  provides  no 
machinery  for  reasoning  about  time  or  situations  that  change  with  time. 

There  are  many  possible  solutions.  Ours  has  been  the  development  of  an  extension  to 
the  first-order  predicate  calculus  by  the  addition  of  sentences  called  stafe  deltas. 
State  deltas  were  first  Introduced  In  [Crocker  77].  For  a  more  formal  treatment  aee 
[Marcus  70].  To  motivate  the  development  of  state  deltas,  we  give  the  observations 
and  decisions  that  support  our  formulation. 

-  It  Is  simple  to  think  In  theoretical  terms  that  a  computer  can  be 
characterized  by  a  transition  function  that  maps  state  vectors  Into  state 
vectors.  Given  an  Initial  state  vector  and  a  statement  of  the  transition 
function,  ordinary  mathematical  tools  will  provide  the  machinery  for 
reasoning  about  successive  states  of  the  machine.  However,  direct  use  of 
this  approach  becomes  unwieldy  for  even  the  simplest  example. 

-  One  of  the  first  difficulties  Is  the  description  of  the  state  vector.  It  Is 
quite  Inconvenient  to  think  of  the  state  vector  as  a  single  domain.  For  all 
real  machines,  the  state  vector  Is  a  messy  patchwork  of  various  domains. 

Each  of  the  storage  locations  in  the  machine  is  a  piece  of  the  state  vector. 

The  primary  memory  Is  perhaps  the  most  regular  component,  but  there  are 
many  other  components.  Also,  It  may  be  desirable  to  subdivide  the  memory 
Into  smaller  pieces.  To  deal  with  this,  we  use  the  usual  programming 
practice  of  assigning  names  to  different  places.  A  place  Is  essentially  a 
component  of  the  state  vector.  Given  the  list  of  places  that  comprise  the 
state  vector,  we  will  not  actually  need  to  symbolize  the  state  vector  as  a 
single  object.  We  will  not  even  need  to  know  exactly  how  the  components 
comprise  the  state  vector,  e.g.,  it  Is  not  necessary  to  know  If  the  state 
vector  Is  represented  as  a  tuple  or  whether  the  program  counter  Is,  say, 
the  first  or  second  element  of  that  tuple. 

-  The  precise  granularity  of  time  Is  not  really  of  Interest.  We  do  not  care 
whether  a  particular  computation  takes  one  or  two  time  steps.  Instead,  we 
care  that  certain  states  follow  one  another  eventually.  Accordingly,  we 
avoid  describing  Individual  transitions  and  describe  the  effect  of  multiple 
transitions  Instead.  The  result  Is  quite  similar  to  Manna  and  Waldlnger's 
Inter  mutant  assertion  Idea  [Manna  &  Waldinger  78],  which  Is  derived  from 
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Burstall's  paper  [Burstall  74].  Wd  make  use  of  a  precondition  and  a 
postcondition,  and  our  state  delta  encodes  the  Idea  that 

If  the  precondition  holds  at  some  point  In  time, 

then  there  will  be  a  later  time  at  which  the  postcondition  holds. 

-  While  It  might  be  possible  to  state  the  behavior  of  a  machine  in  a  single 
sentence,  It  would  be  quite  unwieldy.  We  make  use  of  a  collection  of 
state  deltas  to  specify  the  behavior  of  a  machine.  Each  state  delta 
defines  the  behavior  of  the  machine  in  only  particular  circumstances.  Of 
course,  It  Is  not  necessary  to  cover  all  possible  circumstances;  It  Is 
perfectly  reasonable  to  leave  the  behavior  of  the  machine  undefined  In 
some  cases. 

-  Most  of  the  components  of  the  state  vector  are  unchanged  at  each  step. 
Any  straightforward  description  of  the  transition  function  would  be 
dominated  by  simple  statements  of  equality  between  large  sections  of  the 
old  and  new  states.  To  reduce  this  burden,  our  formalism  encodes  the 
assumption  that  all  of  the  state  remains  unchanged  except  for  a  list  of 
places  In  the  state  vector  explicitly  named.  Accordingly,  a  state  delta  has 
a  modification  Hat.  The  semantics  of  a  state  delta  Includes 

If  the  precondition  holds  at  some  point  In  time, 

then  there  will  come  a  time  at  which  the  new  state  is  the  same 
as  the  present  state  except  possibly  for  the  values  In  the 
places  listed  In  the  modification  list,  and 

at  that  time  the  postcondition  will  also  hold. 

-  Even  with  the  Implicit  assumption  that  most  of  the  state  remains  unchanged 
from  one  state  to  another,  It  may  be  necessary  to  include  many  details  In 
the  precondition.  Quite  often  the  precondition  Includes  the  requirement 
that  much  of  the  present  state  Is  Identical  to  a  particular  prior  state.  This 
introduces  a  third  time  Into  the  formalism.  We  have  encoded  this  condition 
with  another  list  of  places,  called  the  environment  Hat.  The  semantics  of 
state  delta  are  now  stated  as 

If  the  contents  of  the  places  listed  In  the  environment  list  are 
the  same  at  some  time  t1  as  they  were  at  an  earlier  time  tg, 
and 

If  the  precondition  Is  true  at  time  tj, 

then  there  will  be  a  later  time  t^  In  which  the  new  state  Is  the 
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same  as  the  state  at  time  t^  everywhere  except  possibly  at 
the  places  listed  In  the  modification  list,  and 

the  postcondition  will  also  hold. 

To  simplify  our  bookkeeping  about  times  and  states,  we  organize  all  of  our 
thoughts  In  terms  of  a  current  time.  In  the  formulation  above,  we  anchor  tg 
to  the  current  time.  We  can  restate  the  formulation  as 

If  at  some  future  time  t^  all  of  the  values  In  the  places  listed  In 
the  environment  list  are  the  same  as  they  are  now,  and 

If  the  precondition  holds  at  that  time, 

then  there  will  come  a  time  tg  whose  values  are  the  same  as  at 
time  t.j  everywhere  except  possibly  In  the  places  list  In  the 
modification  list,  and 

the  postcondition  will  hold. 

While  this  formulation  Is  quite  close  to  what  we  need  to  support  efficient 
reasoning  about  places  and  states,  the  requirements  imposed  by  the 
modification  and  environment  lists  are  more  difficult  than  they  look.  As 
stated,  It  Is  permitted  that  tho  values  Inside  the  environment  list  and 
outside  the  modification  may  change  In  the  interim,  as  long  as  they  are 
restored  at  the  end  of  the  Interval.  We  have  found  It  more  useful  to 
tighten  this  requirement  so  that  the  values  that  must  be  the  same  at  the 
ends  of  the  time  Intervals  are  In  fact  never  changed  during  the  Intervals. 

It  turns  out  that  tightening  the  restriction  of  the  environment  and 
modification  lists  does  not  remove  any  essential  power.  On  the  contrary, 
this  new  version  allows  the  restricted  use  of  the  modal  operator  "during" 
to  form  sentences  which  are  not  expressible  using  only  pre-  and 
postconditions.  Our  formulation  is  now 

If  the  values  listed  In  the  environment  list  remain  unchanged 
from  now  until  some  future  time,  and 

If  the  precondition  also  holds  at  that  time, 

then  at  the  end  of  some  succeeding  time  Interval  during  which 
at  most  only  the  values  listed  In  the  modification  list  will  have 
changed,  and 


the  postcondition  will  hold. 


microcode  verification 


Note  that  there  Is  no  requirement  that  values  that  are  unchanged  from  now 
until  the  precondition  becomes  true  remain  unchanged  when  the 
postcondition  becomes  true.  In  other  words,  It  is  possible  that  the  same 
place  may  be  listed  In  both  the  enwlronment  and  modification  lists.  Later, 
we  will  see  the  use  and  effect  of  such  an  Intersection. 

The  syntactical  form  of  a  state  delta  in 

(SO  (pre:  P) 

(mod:  M) 

(env:  E) 

(post:  Q) ) 

where  P  and  Q  are  usually  first  order  sentences  In  some  language,  but  may  In  fact  be 
state  deltas  themselves,  and  M  is  a  list  of  places,  as  Is  E.  See  Chapter  4  for  additional 
examples  of  state  deltas. 


Note  that  the  logical  Implication  P  Implies  0  (In  a  given  state)  Is  equivalent  to  the  state 
delta 

(SD  (pre:  P) 

(mod:  ) 

(env:  OMEGA) 

(post:  Q) ) 

being  true  In  that  state,  where  OMEGA  Is  a  list  of  all  places,  or  equivalently  a  single 
state  "containing"  all  others. 


Also  note  that  one  state  delta  may  be  derived  from  two  others  by  a  kind  of  case 
analysis. 


If 

(SO  (pre:  P  AND  P') 

(mod:  fl) 

(env:  E) 

(post:  Q) ) 

and 

(SD  (pre:  P  AND  (NOT  P'll 

(mod:  fl) 

(env:  E) 

(post:  QH 


hold  In  a  certain  state,  then 
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(SO  (pre:  P) 
(nodi  fl) 
(env:  E) 
(postt  Q)) 

holds  In  that  state. 


An  Important  tool  Is  the  "dot"  operator  .R,  which  when  applied  to  a  place  R  (for 
"Register")  represents  the  value  or  contents  of  that  place.  Thus  a  state  change  entails 
a  redefinition  of  dot,  not  a  reinterpretation  of  the  place  Itself. 


When  dot  Is  used  In  a  state  delta  It  always  refers  to  the  contents  at  the  time  of  the 
precondition.  In  order  to  reference  the  contents  of  a  place  at  the  time  of  the 
postcondition,  the  symbol  #  Is  used.  For  example, 

(SO  (pre:  JR  GTR  B) 

(mods  R) 

(envs  ) 

(post:  0R-.R-1)) 

means  that  If  the  value  of  R  is  greater  than  0,  then  at  some  later  time  the  new  value  will 
be  one  less  (and  nothing  changed  along  th«  way  except  for  R). 

Here  Is  an  example  of  deriving  one  state  delta  from  another  by  a  form  of  Induction: 
Assume  the  contents  of  places  are  nonnegative  Integers.  If 

(SO  (pre:  P  ( J?)  AND  it  GTR  0) 

(mod:  Ml 
(env:  E) 

(post:  P (#R)  AND  .R  GTR  AfR) ) 

holds  In  a  certain  state,  and  In  addition  If  M  and  E  represent  disjoint  sets  of  places,  then 

(SO  (pre:  P(.R)  AND  JR  GTR  0) 

(mod:  fl) 

(env:  E) 

(post:  P (0) ) 

holds  In  that  state. 


It  Is  obvious  how  an  Input-output  specification  can  be  stated  using  state  deltas.  In  the 
next  sections  we  shall  explain  how  o  simulation  relation  between  two  programs  can  be 
proved  using  state  deltas. 
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For  now  let  us  point  out  how  a  set  of  slate  deltas  can  be  viewed  as  a  program.  Assume 
that  we  are  given  a  set  of  state  deltas,  ordered  In  some  way,  and  an  "Initial"  state.  The 
first  state  delta  (according  to  the  above  ordering)  whose  precondition  Is  true  In  the 
current  state  may  be  "applied",  thus  transforming  the  state  into  that  specified  by  the 
postcondition  (and  the  modification  list).  Actually  the  term  "state"  should  perhaps  be 
replaced  by  "set  of  states"  since  we  do  not  demand  that  the  postcondition  completely 
determine  the  state;  for  example,  the  actual  values  of  some  places  may  not  be 
determined,  but  rather  some  properties  of  these  values  are  known.  The  components 
(sentences)  of  the  old  state  which  were  dependent  on,  or  "supported  by",  places  In  the 
modification  list  are  removed  from  the  state,  and  the  list  of  sentences  In  the 
postcondition  are  added  to  the  remaining  sentences. 

Now  the  process  Is  repeated  In  the  now  state.  This  process  Is  called  symbolic 
execution. 

It  Is  also  possible  to  view  a  somewhat  arbitrary  program  as  a  set  of  state  deltas,  or  to 
translate  a  program  Into  state  deltas,  us  Is  discussed  in  Section  2.4. 

SIMULATION 

As  stated  In  the  overview,  the  process  of  microcode  verification  can  be  divided  Into  two 
parts:  the  first  showing  that  the  Host  Machine  Implements  the  Target  Machine,  the 
second  showing  that  the  Target  Machine  satisfies  the  Top  Level  Specification.  We  shall 
now  discuss  the  first  of  these  parts. 

Let  us  think  on  the  level  of  abstraction  where  both  the  host  and  microcode  and  the 
target  may  be  considered  as  programs  A?.  Intuitively,  simulates  A?  If  A^  can  "do" 

anything  A?  can;  that  Is,  the  state  changes  due  to  are  reflected  In  the  state  changes 
that  At  causes.  The  state  changes  for  A}  and  A?  separately  are  computed  using  the 
symbolic  execution  of  the  previous  sec  tion  To  prove  that  Aj  (symbolically)  simulates 
we  need  to  establish  a  correspondence  between  the  states  of  At  and  those  of  A2  such 
that  given  two  corresponding  states,  S2  (for  A?)  and  (for  Aj),  If  S2'  Is  the  next  state 
after  S?  arrived  at  by  executing  A2,  then  the  (a)  state  S  '  corresponding  to  S2'  can  be 
arrived  at  by  executing  Aj  from  Sj  (though  S('  need  not  be  the  very  next  state  after  Sj). 
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In  the  system  Implementation,  a  state  Is  specified  (as  In  the  precondition  or 
postcondition  of  a  state  delta)  by  a  list  of  first  order  sentences  and  SDs,  and  the 
correspondence  between  states  Is  specified  by  a  function  called  MAPPING.  Again,  recall 
that  "state"  as  used  here  Is  not  necessarily  a  complete  description.  Thus  MAPPING  Is 
actually  a  correspondence  between  sets  of  complete  states. 

TRANSLATION  OF  ISPS  INTO  SDS 

ISPS  Is  a  relatively  well  known  language  suitable  for  machine  descriptions.  We  will  see 
that  SD  notation  Is  suitable  for  representing  Intermediate  proof  steps,  performing 
symbolic  execution,  and  utilizing  the  efficiency  of  the  modification  list.  In  order  to  retain 
the  advantage  of  ISPS  as  an  Input  language  and  SDs  as  an  Internal  notation,  we  need  to 
translate  ISPS  descriptions  Into  SDs. 

If  we  Invent  a  place  to  represent  the  Internal  control  state  of  a  machine  and  we  assign 
a  symbolic  value  to  the  control  place  for  each  statement  In  an  ISPS  program,  then  the 
program  could  be  represented  with  a  set  of  SDs,  where  each  SD  represents  a  possible 
state  change.  References  to  control  states  could  be  made  by  Including  predicates  of 
the  form  .POIabel  In  the  precondition  and  postcondition  (PC  represents  the  internal 
control  state  "program  counter";  "label"  represents  the  control  value).  Representing  all 
the  state  changes  with  SDs  has  two  drawbacks;  the  thread  of  control  that  Is  Implicit  In 
the  ISPS  representation  Is  lost  and  Is  encoded  explicitly  Into  the  precondition  and 
postcondition;  the  SD  notation  Is  different  from  the  familiar  ISPS  (and  somewhat  more 
complicated). 

Nested  State  Deltas 

The  scheme  we  are  using  Is  motivated  by  the  need  to  model  the  control  mechanism 
Inside  a  machine.  In  an  earlier  formulation,  we  modelled  the  control  mechanism  as  a 
single  variable  that  took  on  explicit  values.  Each  precondition  and  postcondition 
mentioned  the  value,  e.g.,  ,MlcroPC=A31 2,  and  this  control  place  was  also  mentioned  In 
the  modification  list  of  every  SD.  It  did  not,  of  course,  occur  In  the  environment  list. 
Since  the  names  of  the  control  state  values  were  completely  artificial  and  the  explicit 
appearance  In  the  pre-  and  postconditions  of  these  equations  was  very  cumbersome,  we 
revised  the  formulation  to  an  entirely  equivalent  scheme  that  simply  made  Implicit  use  of 
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the  value  of  control  place.  The  only  propeity  of  the  control  place  we  cared  about  Is  that 
It  made  some  precondition  true.  By  embedding  the  next  SD  In  the  postcondition  of  the 
current  SD,  the  next  SD  Is  automatically  made  valid  when  the  current  SD  is  applied 
("executed").  Of  course,  Its  validity  disappears  when  the  control  place  is  changed,  so 
It  Is  necessary  that  the  name  of  the  control  place  appear  in  the  environment  list  of  the 
new  SD.  This  is  what  gives  rise  to  the  appearance  of  the  same  control  place  In  both  the 
environment  and  modification  lists.  Of  course,  there  are  some  SDs  that  will  not  have  the 
control  place  In  the  environment  list.  The  tops  of  loops  need  to  be  around  forever,  and 
we  must  resort  to  using  names  for  the  values  of  the  control  place  at  those  points.  SDs 
that  exit  from  blocks  will  not  generally  have  SDs  in  their  postconditions;  Instead  they  will 
set  relevant  values  of  the  control  place. 

Instead  of  describing  a  program  by  a  set  of  SDs  (one  for  each  possible  state  change)  we 
could  describe  It  with  one  SD  that  represents  the  first  state  change  and  has  a  nested 
SD  that  represents  the  rest  of  the  program  In  its  postcondition.  During  symbolic 
execution,  the  process  of  applying  an  SD  Is  repeated.  The  following  happens  for  each 
SD  application:  the  appropriate  state  change  Is  made;  the  nested  SD  that  represents 
the  rest  of  the  program  Is  added  to  the  current  state;  and  the  SD  Just  applied  is 
removed  from  the  current  state  If  It  is  supported  by  the  (modified)  control  place. 

The  TR  Notation 

The  use  of  the  TR  notation  Is  a  further  compression  of  the  translation  from  ISPS  to  SDs. 
We  noticed  that  It  was  unnecessary  to  translate  an  ISPS  description  entirely  Into  SDs 
and  then  work  with  the  SDs.  Instead,  we  embedded  the  translation  process  In  the 
operation  of  the  proof  system  and  carried  out  just  one  step  of  the  translation  at  a  time. 
In  essence,  we  now  encode  the  value  of  the  control  place  as  a  formula  that  tells  what 
to  do  next.  That  formula  Is  basically  ISPS  code,  with  embellishments  to  tell  us  where  we 
are  In  the  code  and  to  keep  track  of  the  environment  established  by  ISPS  scope  rules. 

To  Improve  the  cumbersome  notation  of  nested  SDs  to  represent  the  tail  of  a  program, 
we  defined  a  function  called  TR  that  maps  an  ISPS  description  into  an  SD  or  a  set  of 
SDs.  We  distinguish  between  ISPS  descriptions  whose  first  statement  Is  an  assignment 
statement  and  those  who  start  with  a  control  change  (conditional  or  unconditional).  In 
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case  of  an  assignment,  the  TR  maps  an  ISPS  program  Into  an  SD  whose  precondition  la 
empty;  the  modllst  Includes  a  control  placn  (MlcroPC)  and  the  name  of  the  register  that 
Is  being  assigned  to;  the  envllst  Includes  only  MlcroPC;  the  postcondition  Includes  the 
effect  of  the  assignment  and  a  TR  whose  parameter  la  the  tall  of  the  ISPS  program.  In 
case  of  a  control  change,  the  TR  maps  an  ISPS  program  Into  a  set  of  SDa.  For  each  8D, 
the  precondition  Includes  the  condition  that  leads  to  the  control  change,  the  modllst  and 
envllst  Include  MlcroPC,  and  the  postcondition  Includes  a  TR  with  the  corresponding  rest 
of  the  ISPS  program.  The  symbolic  execution  using  TRs  Is  very  similar  to  nested  SOa, 
except  that  the  rest  of  the  program  Is  represented  as  a  TR  applied  to  an  ISPS 
description. 

Marking  ISPS  Programs 

The  set  of  SDs  that  represents  an  ISPS  program  Is  not  unique.  We  saw  that  It  ranges 
from  an  SD  for  each  ISPS  statement  to  a  single  SD  for  the  whole  program.  It  depends  on 
the  "granularity"  that  the  ISPS  description  Is  Intended  to  be  broken  Into.  This  granularity 
Is  specified  by  special  markings  of  the  ISPS  description:  Every  SD  that  Is  part  of  the 
description  of  a  marked  ISPS  program  must  cover  a  path  of  execution  between  two 
markings. 

A  control  state  of  an  ISPS  description  Is  a  label  or  a  procedure-entry  (that  specifies  the 
"rest  of  the  program").  A  marking  Is  a  special  kind  of  control  state.  The  minimum  set  of 
markings  needed  to  specify  simulation  are  the  entries  and  exits  of  all  the  procedures. 
Markings  could  be  added  in  order  to  allow  more  SDs  (l.e.,  a  finer  granularity).  They  should 
be  added  to  break  all  the  loops,  for  simplicity.  Marking  should  also  be  added  In  order  to 
avoid  covering  the  same  execution  path  by  more  than  one  SD,  for  efficiency. 

The  Translation  Process 

A  marking  M(  Is  a  "successor"  of  M;  if  M(  belongs  to  the  set  of  markings  that  can  be 
reached  by  symbolic  execution  from  M^  without  visiting  any  other  marking.  The 

translation  algorithm  generates  one  SD  for  each  path  of  execution  between  two 
succeeding  markings  that  are  reachable  from  the  Initial  one.  The  number  of  SDs 
generated  Is  determined  by  the  granularity  (l.e.,  the  number  of  markings).  When  showing 
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Simulation,  wo  will  usually  use  a  very  fine  granularity  for  trie  lower  level  machine  (the 
Host)  and  a  coarser  one  for  the  Target.  The  TR  function  is  used  for  performing  the 
symbolic  execution. 

For  simplicity  we  will  refer  In  this  paragraph  to  the  translation  of  the  target  machine  The 
control  place  for  the  target  machine  Is  MacroPC. 

The  following  Information  Is  accumulated  during  the  symbolic  execution  for  generating 
each  SD:  all  the  "path  conditions"  that  have  to  be  true  In  order  to  reach  a  successor; 
the  list  of  places  that  are  modified  during  execution;  the  new  symbolic  state.  The  new 
SD  covers  the  path  of  execution  between  a  marking  and  Its  successor,  and  Includes  the 
following:  In  the  precondition  the  accumulated  path  condition  and  .MacroPC="lnltlal 
label";  In  the  modllst  the  accumulated  modified  places  and  MacroPC;  the  envllst  Is 
empty;  In  the  postcondition  the  accumulated  symbolic  state  and  .MacroPC*label.  A 
concrete  example  of  translation  of  an  ISPS  program  Is  shown  In  a  subsequent  chapter. 
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3.  THE  SYSTEM 

We  are  building  a  system  to  check  proofs  of  microcode  validity  at  the  two  levels  of  host 
to  target  and  target  to  top-level.  Thus  essentially  the  theorems  to  be  proven  are  of  the 
form:  one  set  of  state  deltas  Implies  another.  The  first  component  Is  a  language  In  which 
to  write  these  proofs.  Then  we  need  a  component  to  perform  some  automatic 
deductions  and  simplifications  to  make  the  checking  of  the  proofsteps  a  manageable 
process.  Finally  we  have  the  Interface  between  the  user  and  the  system  through  which 
the  proof  Itself  Is  Input  and  the  proofchecking  can  be  directed. 

PROOF  LANGUAGE 

Recall  that  the  theorems  to  be  proven  are  of  the  form:  prove  that  a  given  state  delta  Is 
true  In  a  given  state.  Typically,  for  a  iheorem  of  the  form  one  state  delta  Implies 
another,  the  given  state  above  will  be  empty  except  for  the  assumed  state  delta.  In 
the  case  of  Intermediate  lemmas,  the  state  may  contain  special  Information  about  the 
place  values. 

The  main  tools  for  writing  proofs  are: 

Open(S)  S  Is  a  state  delta  to  be  proven.  Open(S)  starts  a  subordinate 

proof.  The  current  state  Is  set  to  the  environment  and 
precondition.  The  Intention  Is  that  now  you  will  try  to  symbolically 
execute  with  state  deltas  In  the  state  until  the  postcondition  of  S 
becomes  true. 

CloseO  Finds  the  previously  Opened  state  delta  and  checks  to  see  If  Its 

postcondition  Is  now  true.  If  so,  then  this  state  delta  Is  thereby 
proved  correct  and  added  to  the  state. 

ComblneCases(S)  Proves  a  state  delta  S  from  two  others  by  case  analysis.  An 
example  Is  given  In  the  Introductory  section  on  state  deltas. 

Performlnductlon(S)  Proves  a  state  delta  from  existing  state  deltas  by  a  form  of 
Induction.  We  shall  not  go  Into  the  details  of  the  specific  Induction 
principle  In  use  at  present. 

THE  SIMPLIFIER 

In  the  following  we  describe  the  principles  behind  some  simplifications  for  expressions  In 
the  state  delta  language.  This  Is  not  Intended  to  be  a  complete  survey  of  all  possible 
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simplifications,  but  rather  a  representative  list  of  those  simplifications  found  useful  in 
the  actual  practice  of  verification,  especially  the  square  root  algorithm  of  the  FTSC. 
Thus  there  Is  a  close  correspondence  between  these  simplifications  and  those  actually 
Implemented  In  the  system.  Here,  though,  we  describe  only  the  "Interesting"  ones,  and 
some  of  these  may  be  stated  In  different  form  without  mentioning  all  the  cases  and 
specifying  the  Implementation  details. 

BSC  (bitstring  constructor)  terms 

The  primitive  operations  for  constructing  bitstrlngs  are  concatenation  a@b,  substring 
selector  a<l:)>,  and  shifts.  The  definitions  of  concatenation  and  shifts  are  standard. 
Our  conventions  for  substring  selector  are  that  bitstrlngs  are  numbered  from  the 
right-most  bit  a<0>  to  the  left-most  a<lh(al-1>  where  lh(a)  Is  the  length  of  a.  Note  that 
we  shall  allow  bitstrlngs  to  have  variable  length.  These  are  called  generalized 
bitstrlngs.  For  Integer  I,  J  a<l:j>  represents  the  string  consisting  of  bits  I  down  to  j  of  a, 
that  is,  a<l>@a<l-1  >...@a<j>.  If  j  Is  greater  than  I,  then  this  string  Is  nonexistent,  and  Is 
called  EMPTY.  If  KO  or  l>lh(a)  then  a<l>  is  EMPTY.  In  the  following  f(i)  and  g(l)  will  be 
functions  attaining  Integer  values  at  Integer  values  of  the  argument  I.  We  will 
occasionally  omit  mention  of  l  and  write  just  f,  g. 

A  (generalized)  substring  Is  a  term  of  the  form  a<f:g>  where  a  Is  atomic. 

A  simplified  substring  Is  the  EMPTY  string  or  Is  a  substring  of  the  form  a<f:g>  where 
VI  f(l)  <  lh(a),  VI  g(l)  £  0,  -VI  f(i)  <  g(|). 

Note  that  when  f  and  g  are  constants,  these  conditions  become  f<lh(a),  g>0,  f>g.  Note 
also  that  we  cannot  demand  Vi  f(l)>g(i),  since  for  example  a<0:-i>  Is  either  EMPTY  or 
a<0>  depending  on  I.  From  our  definition  of  the  semantics  of  substring,  it  follows  that 
any  substring  Is  equivalent  to  a  simplified  substring:  a<f:g>=  a<mln{f,  lh(a)-1), 
max{g,0}>  or  EMPTY.  If  a  canonical  simplified  substring  is  desired,  some  standard 
values  of  f  and  g  will  have  to  be  taken  in  the  case  that  f(l)<g(l),  for  example  f(l)*0  and 
0(0-1. 
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Length  Is  defined  for  a  (generalized)  substring  as  the  following  function  of  I:  (Let  a,  f, 
and  g  be  functions  of  I) 

I  h  (a<  f i g>)  ( I )  -  if  f ( i ) 2  lh(a(i))  then  lh(a< lh(a) -1 tg> (I ) ) 
eleeif  g(i)  <  8  then  lh(a<f t B> ( I ) ) 
el  eel f  f ( I ) <g( i )  then  8 
else  f ( i )-g( i 1+1. 

An  equivalent  closed  form  Is 

lh(a<f:g>)  ■  mln{lh(a),  max{mln{f,  Ih(a)-I)  -  max{g,  0}  1 , 0)} 

This  allows  the  following  rewriting:  Let  0(f)  denote  a  string  of  f  zeroes. 

If  a  Is  of  the  form  0(f)<g:h>,  then  a  =*  0(lh(a)).  (1 ) 

A  BSC  (bitstring  constructor)  term  is  any  term  formed  from  atomic  bltstrlngs, 
concatenation,  substring,  and  shifts. 

A  simplified  BSC  term  Is  of  the  form  b,0b,@...@b  where  n£1  and  each  b  Is  a  simplified 
substring. 

It  can  be  shown  that  every  BSC  term  Is  equivalent  to  a  simplified  BSC  term.  The  main 
simplification  rules  used  In  simplifying  a  BSC  term  are 

(a«b)<f:g>  =>  a<f-lh(b):  g-lh(b)>  0  b<f:g>  (2) 

a  SLO  f  =>  0(mln{lh(a),-f})@a<lh(a)-f-1  :max{-f,0}>@0(mln{lh(a),f})  (3) 

«<f1:gl><f2:g2>  =>  a<mln{f1,f2+gi}:max{g1,g1+g2}>  (4) 

Example  Assume  lh(a)=4,  !h(b)=5,  lh(c)=6. 

(a@(b0c)  SLO  5)<1 3:3X0: 1  >  =* 

(O(-5)@(a0(b@c))<9:O>@O(5))<9:4>  => 

(EMPTY0(a<-2:-1 1  >0(b0c)<9:O»0O(5))<9:4>  =* 

(b<3:O>0c<9:O>0O(5))<9:4>  ^ 

(b<3:O>@c0O(5))<9:4>  => 


C<4:O>0O(1) 
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BSA  (bitstring  arithmetic)  terms 

All  the  bitstring  addition  operators  are  translated  Into  BITPLUS;  BITPLUS  Is  noncarry 
addition  between  two  bltstrlngs  of  equal  length.  When  the  sign  ♦  appears  between 
bltstrlngs  It  will  always  denote  BITPLUS.  We  also  use  *  for  numerical  addition,  but  It  Is 
clear  from  the  context  which  Is  Intended.  USVAL(a)  Is  the  nonnegative  Integer 
represented  In  binary  by  the  bitstring  a 

If  b  and  c  are  constant  bltstrlngs  and  USVAl.(b)+USVAL(c)  <  2lh(b),  then 

(a@b)*c  =*  aQ(b«-c)<lh(b)-1:0>  (5) 

A  similar  simplification  rule  holds  for  c+|a@b).  Of  course  the  two  sides  of  5  are 
equivalent  even  If  b  and  c  are  not  constants,  but  then  the  right  side  Is  not  necessarily 
simpler. 

BSB  (bitstring  relational)  terms 

There  are  two  main  classes  of  bitstring  relations:  unsigned  value  and  two's  complement. 
Every  unsigned  bitstring  relation  Is  equivalent  to  the  the  corresponding  real  relation  on 
the  USVAL's  of  Its  arguments  For  example,  USEQL(a.b)  Is  equivalent  to 
USVAL(a)=USVAL(b).  Similarly  for  two's  complement.  The  simplification  of  this  type  of 
relation  will  be  given  In  this  section.  The  section  on  real  relations  will  Include  (among 
others)  "mixed  relations",  l.e.,  those  containing  both  USVAL  and  TCVAL.  TCVAL(a)  is  the 
(signed)  Integer  which  Is  the  two's  complement  Interpretation  of  the  bitstring  a. 

Equality 

We  let  a  =,jS  b  denote  USEQL(a,b)=T  and  similarly  for  TCEQL.  We  write  *  with  no 
subscript  if  Identity  between  bltstrlngs  is  Intended. 

•f  VIJ  (fjdXjSfjd)  V  yiXJSfjd)  -->a<J>*0),  then 

a<fi:g>  =US  a<Vg>  (6) 

lf  ai  “us  *2  and  bi  =US  bz  and  •Wl»1)*lh(b2).or  if  b,  =us  b2<lh(bj)-1 :0>  and  a,  =us 
a2@b2<lh(b2)-1  dhfbj)),  then 

2  'S 
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•1®b!  'US  a2Sb2 


If  a  «yS  0  and  b  «us  0,  then 
a8b  -us  0 


Of  course,  there  are  the  obvious  generalisations  when  an  arbitrary  constant  la  In  place 


»  ai  “US  a2  and  bi  'US  b2  or  al  'US  b2  and  bi  "US  a2* then 


Vbi  "US  Vb2 


If  USVAL(a)£2*b^a^-2*  or  0>TCVAL(a)>-2f-1,  then 


a<f>  ■  1  7 

If  a<f1:gl>  *us  0  for  some  tjtf,  g^g,  then 

a<f:g>  *ys  0  (11> 

If  a  b  and  a<lh(a)-1>  «  b<lh(b)-1  >  (or  lh(a)=lh(b)),  then 

U  k  (12) 

a  “tc  b 

If  a<f>  ■  a<f>1 >  «  ...  ■  a<lh(a)-1>,  then 
a<f:0>  =TC  a 

If  a<f*1>«a<f>*a<f-1>  and  b<f*1>=b<f>sb<f-1>,  then 
(a  ♦  b)<f>  *  (a  ♦  b)<f*1  > 

If  Vfll“Vfl2’  a<V!«l,>  *US  b<f2':02,>’  f|^fr  91 -91’  fi~fl  “  f2  "V  0»'°‘  “  °2"°2  ’ 

or  If  a<lh(a)-1:8l>  «us  b<lh(b)-1  g2>,  a<f1*1>«...*a<lh(a)-1  >»0, 

b<f?+1  >»...sb<lh(b)-1  >«0,  then 

a<fr0i>  “us  b<,2:®2>  (15) 


Ordering 

0  *TC  a 

If  and  only  If  a<lh(a)-1>«0. 


(16) 
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BSV  (bitstring  value)  terms 
If  a<lh(a)-1  >=0,  then 

TCVAL(a)  ^  USVAL(a)  (17) 

If  a<lh(a)-1  >*0,  then 

USVAL(a)  =*  USVAL(a<lh(a)-2:0>)  ( 1 8) 

TCVAL(aOb)  =>  2,h(b)»TCVAL(a)  +  USVAL(b)  ( 1 0) 

USVAL(aSb)  =>  2,h(b)«USVAL(a)  +  USVAL(b)  (20) 

If  lh(a)»lh(b),  a<f-1  >»b<f-1  >«0,  a<f>=a<f+1  >*...»a<lh(a)-1  >,  b<f>*b<f*1>»...«b<lh(b)-1>, 
then 

TCVAL((a+b)<f:0»  =*  TCVAL(a+b)  (21) 

If  lh(a)=lh(b)  and  TCVAL(a)  ♦  TCVAL(b)  >  a1*’*®*"1,  then 

TCVAL(a+b)  =>  TCVAL(a)*TCVAL(b)-2,h(a)  (22) 

If  lh(a)=lh(b)  and  TCVAL(a)  ♦  TCVAL(b)  <  •?lh(a)'1,  then 

TCVAL(a+b)  =>  TCVAL(a)  ♦  TCVAL(b)  +  2,h(a)  (23) 

If  lh(a)=lh(b)  and  -2lb(a)_1  STCVAL(a)  ♦  TCVAL(b)  <2lh(a)_1 ,  then 

TCVAL(a+b)  =*  TCVAL(a)  ♦  TCVAL(b).  (24) 

RA  (real  arithmetic)  terms 

We  list  here  only  the  rules  concerning  RA  terms  which  contain  BSV  terms. 

Let  Cj  and  c?  be  functions  of  I  (as  are  the  f's  and  g's).  If  Cj.c^O,  fjfcf2,  9j*92>  and 
Vl(c1(l)?<c2(l)  =>  g2(l)>f2(l)),  then 

c1*v(a<f1:g1>)  -  c2*v(a<f2:g2>)  =>  (25) 

c^2max(f2-82*1lO),w(a<f^s9^max(f^^+1  0)>) 

Note  that  we  do  not  demand  that  Vl(f2>g2). 

If  a<lh(a)-1  >=1,  then 

TCVAL(a)  «•  2lh(a)  =*  USVAL(a).  (26) 

21 
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RR  (real  relational)  terms 

TCVAL(a<lh(a)-1:n»  i  2~n* TCVAl(a)  (27) 

THE  USER  INTERFACE 

The  SD  proofchecker  Is  controlled  by  the  Kernel  which  executes  a  sequence  of  low 
level  proofsteps  that  are  submitted  to  it  by  the  User  Interface.  The  User  Interface 
assists  the  user  In  entering  the  proofsteps  In  the  right  format  (User  Mode);  In  entering 
groups  of  proofsteps  that  were  prepaied  earlier  (Batch  Mode);  and  In  entering 
frequently  used  sequences  of  proofsteps  (Propose  Mode  or  Symbolic  Simulate).  The 
User  Interface  provides  miscellaneous  services  (In  Exec  Mode)  such  as  Initialization,  l.e., 
assigning  a  fixed  symbolic  value  to  contents  of  places,  probing  the  status  of  the  proof, 
redoing  proofsteps,  entering  other  modes,  etc.  Following  are  some  more  details  about 
using  the  User  Interface. 


The  Exec  Mode  Is  Initiated  from  INTERLISP  by  evaluating  "(StartExec)";  It  Is  suspended 
by  "QUIT";  and  restarted  by  "(ContlnueExec)".  In  addition  to  calling  the  other  modes, 
Exec  Mode  does  the  following: 


FIxLast 


GetlSPS 


ResetProof 


SetSwItches 


DlsplayState 


allows  editing  and  resubmitting  the  last  proofstep  that  was 
submitted  to  the  Kernel  (useful  in  case  of  failure). 

vsubmlts  an  "Open"  and  sequence  of  "NewDecompositlon"s  that 
setup  proofs  that  Involve  Symbolic  Execution  of  ISPS  programs. 

resets  the  whole  proof  system. 

sets  or  resets  one  of  the  trace  switches. 

displays  separately  the  following  parts  of  the  current  state:  State 
Deltas,  Variable  Values,  General  Facts,  Coverings,  Mappings,  Place 
Map,  and  Other  Predicates. 


User  Mode  assists  the  user  in  constructing  the  correct  format  of  the  proofsteps  and 
allows  the  user  to  correct  the  proofsiep  and  okay  It  before  submitting  to  the  Kernel. 
User  Mode  uses  the  full  power  of  the  INTEFII.ISP  editor  and  ASKUSER. 
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A  batch  Is  a  sequence  of  proofsteps.  It  can  be  edited  off-line  and  generated  by  the 
"Transcript"  trace.  Batch  Mode  takes  the  following  commands: 

PerformNext  submits  the  next  proofstep  from  the  batch. 

Oolt  submits  the  next  n  proofsteps  from  the  batch. 

DIsplayNext  shows  the  proofstep  that  PerformNext  would  perform. 

SklpNext  skips  the  proofstep  that  PerformNext  would  submit. 

The  User  Interface  Includes  two  heuristics,  one  for  symbolic  execution  and  one  for 
symbolic  simulation.  The  one  for  symbolic  execution  Is  referred  to  as  ProposeMode,  for 
historical  reasons.  ProposeMode  generates  and  submits  proofsteps  until  one  of  the 
following  conditions  Is  met:  Control-Y  Is  Issued,  a  "Close"  proofstep  Is  submitted,  the 
breakpoint  Is  true  In  the  current  state,  or  it  has  nothing  to  propose.  The  only  proofsteps 
It  (currently)  tries  to  propose  are  "Close"  and  "ApplySD". 

The  Symbolic  Simulation  heuristic  generates  and  submits  the  following  sequence  of 
proofsteps  for  each  SD  In  the  current  "GOAL":  Open  the  SD;  Apply  a  mapping;  Propose 
till  the  state  can  be  mapped  again;  Apply  a  mapping;  Close.  An  additional  "Close"  Is 
submitted  to  add  the  "GOAL"  to  the  current  state. 
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4.  EXPERIENCE  AND  EXAMPLES 

Th®  bulk  of  our  work  has  used  examples  taken  from  the  FTSC.  Ae  we  outlined  In  the 
overview,  we  have  divided  the  FTSC  target  description  Into  two  levels.  One  level 
provides  an  algorithmic  description  for  the  Instructions.  For  the  simple  Instructions,  e.g., 
load,  store,  and  Integer  arithmetic  Instructions,  this  level  of  description  Is  easy  to  read 
and  requires  no  further  refinement.  However,  for  the  floating  point  Instructions,  an 
algorithmic  description  of  the  effect  of  an  Instruction  Is  nearly  opaque  and  Is  useful  only 
to  a  specialist  who  needs  to  track  down  the  detailed  results  for  particular  cases.  For 
these  Instructions,  we  need  to  prove  that  the  results  guaranteed  by  the  algorithmic 
description  may  be  understood  In  terms  of  some  simply  stated  properties.  The  square 
root  Instruction  Is  the  most  Interesting  example  In  this  area,  and  we  have  focused  most 
of  our  attention  on  proving  Just  the  simple  property  that  the  effect  of  the  square  root 
Instruction  as  described  by  the  algorithmic  description  does  Indeed  compute  the  largest 
floating  point  number  whose  square  Is  not  greater  than  the  original  number.  We  felt  this 
example  would  expose  the  hardest  Issues  first  and  provide  some  chance  that  the  rest 
of  the  proof  would  be  comparatively  easy.  We  have  not  yet  determined  whether  this 
strategy  will  be  successful. 

At  the  same  time,  we  have  been  concerned  that  the  mechanics  of  carrying  out  a 
complete  proof  should  be  well  understood.  Accordingly,  we  have  hedged  our  bets  a  bit 
and  constructed  a  very  small  fictitious  example  of  a  mlcrocoded  machine,  written  the 
microcode  to  Implement  a  simple  Instruction  set  for  that  machine,  and  prepared  a 
complete  proof.  We  call  the  machine  the  "roY"  machine. 

This  chapter  details  the  proofs  for  both  of  these  examples.  To  give  the  flavor  of  a 
complete  proof,  we  present  the  TOY  machine  first. 

THE  TOY  MACHINE 

The  TOY  machine  Is  a  simple  microprogrammed  machine.  We  have  provided  a  formal 
description  of  Its  target  Instruction  set  and  of  Its  host  architecture.  We  have  written 
the  microcode  for  the  host  level  that  Implements  the  target  Instruction  set,  and  we  have 
specified  the  states  In  the  host  and  target  levels  that  correspond  to  each  other. 


VI 
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Finally,  we  have  written  a  set  of  commands  for  the  proofchecker  to  guide  It  toward 
proving  that  when  the  microcode  runs  on  the  host  machine,  It  correctly  implements  the 
target  Instruction  set.  For  a  problem  this  simple,  the  commands  to  the  proofchecker  are 
entirely  devoted  to  setting  up  the  proof.  The  actual  details  are  carried  out  completely 
automatically. 

The  TARGET  Machine 

In  order  to  keep  this  experiment  simple,  but  still  deal  with  a  realistic  machine,  we 
designed  the  TARGET  machine  according  to  the  following  requirements: 

-  4K-word  18-blt  memory 

-  a  12-blt  program  counter,  a  16-blt  accumulator,  and  a  10-blt  Instruct 
register 

-  Infinite  Indirect  addressing 

-  six  possible  operations:  add,  subtract,  store,  load,  skip  or  negative,  Jump. 

We  decided  on  the  following  word  format: 

IS  13  12  11 

4— - - - - - - - - 

I  I  I 

I  OPCODE  1 1  NO  |  EA 

I  I  I 

♦ - 4 . . . . 

TOY  starts  operating  by  fetching  the  Instruction  from  location  1  In  memory.  It  proceeds 
by  repeating  the  cycle  of  execution  and  fetching 

Fetching  Is  performed  as  follows:  the  machine  loads  the  Instruction  register  from  the 
memory  location  that  the  program  counter  points  to;  while  the  Indirect  bit  Is  set,  the  13 
least  significant  bits  of  the  Instruction  register  are  overwritten  by  the  contents  of  the 
memory  location  that  the  effective  address  (EA)  points  to;  then  the  program  counter  Is 
Incremented 
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The  execution  performs  one  of  the  following  operations  according  to  the  3-blt  opcode: 
add  MEM[EA]  to  the  accumulator;  subtract  MEM[EA]  from  the  accumulator;  load  the 
accumulator  with  MEM[EA];  store  the  contents  of  the  accumulator  In  MEM[EA];  skip  the 
next  operation  If  the  most  significant  bit  of  the  accumulator  Is  one  (negative 
accumulate);  Jump  to  EA. 

The  precise  ISPS  description  of  the  TARGET  machine  was  written  according  to  the 
English  description  and  Is  shown  In  Figure  1.  The  ISPS  program  Is  divided  into  the 
following  declarations:  the  memory;  the  registers;  the  fetching  algorithm;  the  execution 
algorithm;  the  main  cycle. 

The  markings  we  selected  In  the  TARGET  machine  are  the  labels  MAIN,  XFETCH,  FLOOP, 
and  EXEC.  The  paths  that  the  algorithm  found  were  one  from  MAIN  to  FETCH,  one  from 
FETCH  to  FIOOP,  one  from  FIOOP  to  FlOOP,  one  from  FLOOP  to  EXEC,  nine  from  EXEC  to 
FETCH. 

MacroPC  Is  a  dummy  place  that  holds  the  control  state  (the  label)  and  TlnvReg  covers 
the  Internal  registers  The  complete  set  of  SDs  that  the  ISPS  to  SD  algorithm  found  Is 
Shown  In  Figure  2.  Let  us  look  closer,  for  example,  at  the  third  SD:  It  describes  the  path 
from  FLOOP  to  EXEC  which  Is  denoted  by  MacroPC=FLOOP  In  the  pre :  and 
#MacroPC  =  EXEC  In  the  post:.  The  pre.-  also  Includes  .IR<  1 2>*0,  which  Is  the 
precondition  for  taking  this  particular  path  The  post:  Includes  also  the  new  value  of  PC, 
PC-H . 

Tha  HOST  Machine  and  the  Microcode 

The  HOST  machine  Is  the  actual  hardware  that  implements  the  TOY  machine.  Because 
the  goal  of  this  experiment  Is  microprogram  verification,  we  chose  a  microprogrammed 
HOST.  The  HOST  machine  was  somewhat  tailored  to  the  TARGET,  for  simplicity,  but  still 
much  generality  and  extendablllty  were  maintained.  The  description  of  the  HOST 
machine  explicates  all  the  details  of  registers,  combination  circuits,  and  data  paths. 
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TARGET 


BEGIN 

i VA  Memory  A  A 

MEM (0:4k) <15: 0> 
a  a  Registers  Art 

PC<11:0>,  !  program  counter 

ACC<15:0>,  !  accumulator 

IR<15:0>,  !  instruction  register 

OPCODE<2:0>  :«  1R<15:13>,  !  operation  code 

EA<11:0>  :«  IR<11:0>  !  effective  address 

Art  Instruct  ion. Fetching  Art 
XFETCH  t-  BEGIN 

IR  MEM [PCI  NEXT 
FL00P1  REPEAT 

FLOOP  DECODE  IR<12>  => 

BEGIN 

0  LEAVE  FL00P1 , 

1  I R<12: 0>  -  MEMIEA) 

END 

NEXT  PC  *-  PC  +  1 
END 

A*  I ne true t i on. Execu t i on  AA 
EXEC  i-  BEGIN 

DECODE  0PC00E  -> 

BEGIN 

0\AOO  ACC  ACC  +  MEM  IEAI , 

1\SUB  ACC  •  ACC  -  MEMIEA] , 

?\STR  MEMIEA]  -  ACC. 

3\L0A0  ACC  -  MEMIEA], 

AXSKPN  IF  ACC<15>  ■  >  PC  •-  PC  +  1, 
5\JMP  PC  -  EA, 

6  NO. OP  0. 

7  j-  NO. OP  I) 

END 

END 

**  Execution. Cyc I e  aa 
CYCLE  (MAIN!  i-  BEGIN 
PC-1  NEXT 
REPEAT 

BEGIN 

XFETCH ( )  NEXT 
EXECO 
END 
END 
END 


Figure  1.  ISPS  description  of  the  TARGET  machine 


!  program  counter  init 

!  call  fetch  a  I gor i thm 
!  call  execution  algorithm 
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((SO  (pres  (.MacroPC) -MAIN) 

(mod:  TlnvReg  MacroPC  PC) 

(env: ) 

(post:  /WacroPC-XFETCH  tfPC-1 ( 12) ) ) 

(SO  (pre:  (.MacroPC) =XFETCH) 

(mod:  TlnvReg  Macrc.PC  1R) 

(env: ) 

(post:  tfTlacroPC.FLOOP  #IR-(D0T  (UORDS  MEM  .PC  .PC] 

(SO  (pre:  (.MacroPC) -FL00P 

(NZEROP  (USEQL  (DOT  (BITS  IR  12)) 

0))) 

(mod:  TlnvReg  MacroPC  PC) 

(env: ) 

(post:  WlacroPC-EXEC  «PC- (B1 TPLUS  .PC  1(12)))) 

(SO  (pre:  (.MacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13) ) ) 

0))) 

(m-'d:  TlnvReg  MacroPC  ACC) 

(env: ) 

(post:  MlacroPC-XFETCH  #ACC» (B! TPLUS 
.ACC 

(001  (UORDS  MEM  (USSUB  .IR  11  0) 

(USSUB  .IR  11  01 

(SO  (pre:  (.MacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13))) 

1))) 

(mod:  TlnvReg  MacroPC  ACC) 

(env: ) 

(post:  ttlacroPC-XFETCH  #ACC» (B I TPLUS 
.ACC 

(B! (MINUS  (DOT  (UORDS  MFM 

(USSUB  .IR  11  0) 

(USSUB  .IR  11  01 

(SO  (pre:  (.MacroPC) -EXEw 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

2))) 

(mod:  TInvRea  MacroPC 

(UOROS'MEN  (00T  (BITS  IR  (PAIR  11  0) 

(env: ) 

(post:  ffMacroPC.-XFETCH  # (UORDS  MEM 

(USSUB  .IR  11  0) 

(USSUB  . IR  11  01 1 - ( . ACC) ) ) 

(SO  (pre:  (. MacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

3H) 

(mod:  TlnvReg  MacroPC  ACC) 

(env: ) 

(post:  tfMacroPC-XFETCH  #ACC-(D0T  (UORDS  MEM 

(USSUB  .IR  11  0) 
(USSUB  .IR  11  0) 

Figure  2.  The  SD  description  of  the  TARGET 
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<S0  [pres  (.flacroPC)  »EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  IS  13))) 

4)) 

(NZEROP  (DOT  (BITS  ACC  15) 

(modi  TInvRea  flacroPC  PC) 

(env: ) 

(posts  tfflacroPC-XFETCH  #PC-(BITPLUS  .PC  1(12)))) 
(SO  (pre:  (.FlacroPC) -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

4)  ) 

~ (NZEROP  i DOT  (BITS  ACC  15) 

(mod:  TInvRea  flacroPC) 

(env: ) 

(post:  tfflacroPC-'XFETCH) ) 

(SO  (pre:  (.FlacroPC) -=EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

5)  ) ) 

(mod:  TinvReg  flacroPC  PC) 

(env: ) 

(post:  tfflacroPC'XFETCH  #PC- (USSUB  .IR  11  0))) 

(SO  (pre:  (.FlacroPC)  "EXEC 

(NZEROF  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

6)  ) ) 

(mod:  TInvRea  flacroPC) 

(env: ) 

(post:  tfflacroPC'-XFETCH)  ) 

(SO  (pre:  (. flacroPC)  -EXEC 

(NZEROP  (USEQL  (DOT  (BITS  IR  (PAIR  15  13))) 

7))) 

(mod:  TInvRog  flacroPC) 

(env: ) 

(post:  tfMdcr  (.PC'XFETCH) ) 

(SO  (pre:  (. flacroPC) -FL00P 

(NZEROP  (USEQL  (DOT  (BITS  IR  12)) 

1))) 

(mod:  TInvRea  flacroPC  IR) 

(env: ) 

(post:  tfflacroFC.FLOOP  #IR-(USC0NC 
(USSUB  .IR  15  13) 

(US5UB  (DOT  (WORDS  HEf1  (USSUB  .IR  11  0) 
(USSUB  .IR  11  0))) 

12  0) 


Figure  2.  (continued) 
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We  decided  to  keep  the  microprogram  In  a  64-word  21  -bit  ROM.  ROM  words  contain 
21 -bit  microinstructions  with  the  following  format: 

19  18  16  15  13  12  11  98  65  0 

+ - + - + - - - + - + - + - + 

I  I  I  I  I  I  I  I  I  I 

I  I  HUX  |  |  ALU  |  |  HD  |  LATCH  |  HPC  |  MNEXT  | 

I  I  I  I  I  I  I  I  I  I 

+ - - - ♦ . . . + . ♦— . 4- - + 

The  HOST  machine  (see  schematic  In  Figure  3)  Includes  the  following:  two  memories, 
STORE,  and  ROM;  registers  R1,  R2,  R3,  MAD,  MPC  (microprogram  counter)  and  Ml 
(microinstruction  register);  combinational  circuits  ALU,  MD,  and  MUX;  data  paths;  the 
scanner.  R1  holds  the  value  from  the  ALU  that  receives  its  value  either  from  STORE  or 
from  R 1 ;  R2  holds  the  value  from  R3  or  Increments  Its  old  value;  R3  holds  the  value  from 
MD  that  receives  Its  value  from  STORE  or  R3;  MAD  holds  the  value  from  MUX  that 
receives  Its  value  either  from  R2  or  R3. 

The  HOST  repeats  the  cycle  of  loading  the  microinstruction  register  from  the  location  In 
ROM  that  the  microprogram  counter  points  to;  Incrementing  the  microprogram  counter; 
and  scanning  the  microinstruction  and  decoding  a  field  at  a  time.  The  scanner  sends 
signals  that  establish  data  paths  and  latch  values  into  registers.  It  also  receives  values 
from  registers. 

The  precise  ISPS  description  of  the  HOST  machine  Is  shown  In  Figure  4,  and  the 
description  of  the  ROM  In  Figure  5.  The  description  of  the  HOST  includes  the  following 
declarations:  the  memories;  the  registers;  the  combinational  logic;  and  the  execution 
cycle  that  fetches  and  scans  the  IR.  The  microprogram  Is  specified  as  a  set  of 
assignments  to  ROM.  The  comment  In  each  assignment  shows  the  microinstruction  In  a 
mnemonic  form:  The  nonzero  fields  of  each  microinstruction  are  separated  by  @.  The 
mnemonics  correspond  to  the  ones  In  the  DECODE  statements  In  Figure  4.  For  example, 

MUXR3@LMADQ0NIND@10  means  that  MUX  =  3,  ALU  =  0,  MD  «  0,  LATCH  »  6,  MPC  ■  2  and 
MNEXT  =  10. 
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HOST  i -  BEGIN 


**  Memory  ft* 
ROM(0:G3]<2010>, 

STORE (0i 4k) <15* 0> 

**  Registers  ft* 

MPC<5:0>,  ! 

MI  <20: 0>,  '■ 

MNEXT<5:0>  «-  MI<5:0>,  ! 

Rl<15:0>,  ! 

R2<11:0>.  '■ 

R3<15: 0>,  ! 

MAO<11:0>  '■ 

**  Combinat lonal .Clrcui  ts 
ALU<1S:0>.  '■ 

MUX<11:0>.  t 

ND<15:0>  '■ 


micro  program  counter 
micro  instruction  register 
next  micro  instruction 
Accumu I ator 
Program  Counter 
Instruction  Register 
memory  address 

VnV 

arithmetic,  logic  unit 
memory  address  multiplexer 
memory  data  multiplexer 


*ft  Execut I  on. Cycle  ftft 
CYCLE  IMA IN)  BEGIN 
REPEAT 
BEGIN 

MI  -  ROMtMPCl  NEXT 
MPC  *•  MPC  +  1 
NEXT 

DECODE  MI <19: 18>  »> 

BEGIN 

0  NO. OP  O, 

1  NO. OP  0, 

2\MUXR2  i-  MUX  •-  R2<12»0>, 
3NMUXR3  i«  MUX  *•  R3<lli0> 
END  NEXT 


OECOOE  MI <1B: 15>  -> 

BEGIN 

0  NO. OP  0, 

1  \ALUNOP  ALU  ♦*  STORE  [MAD], 

2XALUA0D  :«  ALU  «-  R1  +  STORE  [MAD], 
3NALUSU0  Al.U  •-  R1  -  STORE  [MAO] 

END  NEXT 

DECODE  MI <13: 12>  -> 

BEGIN 

0  NO. OP  O, 

1  NO. OP  O, 

2\ALL  :»  MD  *-  STORE  [MAD] , 

3\ADD  MD  *■  R3<15:13>  STORE  IMAD1  <12t0> 
END  NEXT 

Figure  4.  ISPS  description  of  the  HOST 
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DECODE 


MI <11: 3>  »> 
BEGIN 
0  NO. OP 


0, 


1NLR1 
2\LR2 
3\LR3 
4UNCR2  i 
5M4RI  TE  : 
B\LMAD  s- 
7MNIT  s- 
ENO  NEXT 


:0>, 


ALU. 
FI3<11: 

MO. 

-  R2  +  1. 
STORE (MAOJ  - 
MAD  .•  MUX, 

P2  »•  1 


R2 


Rl. 


DECODE  Ml<8:6>  -> 

BEGIN 

0  NO. OP  0. 

1S0NP0S  IP  NOT  R1<1S>  ->  MPC  -  MNEXT, 
2N0NIN0  :»  IF  R3<12>  ->  MPC  -  MNEXT, 

3  s-  NO. OP  O. 

4\NXT  MPC  MNEXT, 

5  NO. OP  0, 

6  s-  NO. OP  0, 

7X0N0P  MPC  -  R3<1S:13> 

END 

END 

END 


Figure  4.  (continued) 
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BEGIN 


•frit  Memory  *ft 
ROM  (0iG3I<20!0> 


ft*  Execut I on.Cyc I e  a* 

CYCLE (MAIN!  s- 
BEGIN 

ROM (01  -  #0201410  5 
ROM  (11  -  #0301410  5 
ROM  [21  ♦-  #0005410  s 
ROM  (31  -  #0101410  s 
ROM (41  #0000415  ; 

ROM  (51  v  #0002410  ; 
ROM  (51  #0009410  ; 

ROM (71  #0000410  ; 

ROM  (81  -  #2005000  i 
ROM  (91  -  #0023413  : 
ROM  (101  -  #0033000  •. 
ROM (111  -  #3006212  s 
ROM  (121  -  #0004000  t 
ROM  (131  -  #0000700  i 
ROM  (141  4-  #0000110  ? 
ROM (151  -  #0004410  i 
ROM  (151  -  #0007410 
NEXT  EXEC  NO-OP  0 
END 
END 


!  ALUAD09LR1»NXT«8 
!  ALUSUB®LRleNXT#8 
!  URI TE®NXT*8 
!  ALUNOP#LRl«NXT*8 
!  NXTal4 
!  LR2aNXT«8 
!  NXT@8 
!  NXT98 

!  FETCH 1  MUXR2«LMAD 
!  ALL9lR3®NXT9ll 
!  ADD®LR3 

!  FLOOPi  MUXR3eLMAD#0N  I  NOel  0 
!  EXECt  INCR2 
!  ONOP90 
!  0NP0S®8 
!  INCR2«NXT»8 
!  INIT9NXT«8 


Figure  5.  The  specification  of  the  Microcode 
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The  first  phase  of  the  proof  converts  the  ISPS  description  of  the  HOST  Into  a  single  SD 

whose  post:  field  Includes  the  complete  representation  of  the  HOST.  This  SD  Is  used  In 
the  next  section  as  the  specification  of  the  control  state  of  the  HOST  In  the  mapping. 
The  ISPS  description  of  the  microcode  Is  converted  to  SD  notation  too. 

The  current  Implementation  requires  that  the  ISPS  description  of  the  HOST  consist  of  a 
single  cycle,  for  reasons  of  simplicity.  The  HOST  will  indeed  usually  be  a  single  cycle 
because  It  represents  hardware.  Minor  Implementation  changes  will  accommodate 
arbitrary  ISPS  descriptions  of  the  HOST. 

The  next  section  Introduces  the  mapping  and  the  following  section  explains  how  the 
symbolic  simulation  of  the  TARGET  by  the  microprogrammed  HOST  machine  Is  set  up  and 
performed. 

Relating  the  TARGET  and  the  HOST 

In  order  to  show  that  one  machine  simulates  another,  a  relation  between  the  two  must 
be  established.  The  relation  addresses  control  Issues  and  data  Issues.  The  control  part 
of  the  relation  specifies  all  the  pairs  of  control  states  (In  the  TARGET  and  HOST, 
respectively)  that  have  the  following  properties:  whenever  a  control  state  Is  reached  In 
one  machine  then  the  corresponding  one  Is  reached  In  the  other  machine.  Two  obvious 
pairs  are  the  pair  of  Initial  states  and  the  pair  of  final  states.  A  necessary  condition  for 
simulation  (of  terminating  machines)  Is  that  corresponding  Initial  states  always  lead  to 
corresponding  final  states.  The  data  part  of  the  relation  specifies  the  pairs  of  carriers 
that  should  have  the  same  contents  whenever  a  pair  of  control  states  Is  reached.  This 
data  relation  Is  called  a  covering. 

The  control  states  In  the  TARGET  machine  to  be  mapped  from  or  to  were  selected  as  the 
set  of  all  the  markings.  For  the  particular  TOY  machine  example  the  following  markings 
were  selected:  the  Initial  state  Is  MAIN;  the  top  of  the  main  cycle  Is  XFETCH;  the  Infinite 
fetch  loop  Is  broken  at  FLOOP;  the  fetch  algorithm  Is  separated  from  the  execution 
algorithm  at  all  the  control  states  In  the  TARGET  map  to  or  from  a  state  described  by  the 
top  of  cycle  of  the  HOST  and  an  additional  predicate  (usually  the  value  of  the 
microprogram  counter). 
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The  top  of  Figure  6  shows  a  set  of  control  relations;  the  first  element  of  each  Is  a 
marking  (represented  by  an  ISPS  label)  In  the  TARGET  and  the  rest  Is  a  predicate  that 
together  with  the  code  of  the  HOST  makes  up  Its  control  state.  The  bottom  of  Figure  8 
shows  the  coverings  that  specify  the  relation  between  registers  (or  memories)  In  the 
TARGET  to  registers  (or  memories)  In  the  HOST. 

During  the  first  phase  of  the  proof,  a  set  of  Internal  MAPPING  records  Is  generated  from 
the  concise  representation  of  Figure  6.  Figure  7  shows  two  out  of  the  eight  mappings.  A 
MAPPING  record  has  three  fields:  from:,  that  specifies  the  '  ontrol  state  of  either  the 
TARGET  or  the  HOST;  to:,  that  specifies  the  corresponding  control  state  of  the  other 
machine;  and  map:,  that  specifies  the  covering.  The  notion  of  MAPPING  records  Is  built 
Into  the  SO  proofchecker  and  Is  used  In  the  second  phase. 

We  have  described  the  TARGET,  the  HOST+mlcrocode,  and  the  relation  between  them  In 
three  forms:  English,  formal,  and  a  form  that  can  be  processed  by  the  SD  proofchecker. 
The  first  phase  of  the  proof  generated  the  batch  of  SO  commands  from  the  formal 
descriptions. 

Symbolic  Simulation 

The  previous  sections  presented  the  TARGET  machine,  the  HOST  machine  with  Its 
microprogram,  and  the  mapping  between  the  machines.  This  section  shows  how  the 
proof  of  simulation  of  the  TARGET  by  the  HOST  with  respect  to  the  mapping  was 
performed  using  the  SD  command  batch.  The  simulation  Is  performed  within  the  state 
delta  symbolic  execution  framework,  thus  It  Is  called  symbolic  simulation. 

The  SD  proof  system  operates  by  maintaining  a  "current  state"  of  the  execution,  which 
can  be  manipulated  by  opening  or  closing  proofs,  or  by  applying  SDs  or  mappings.  A  SD 
Is  a  notation  for  specifying  a  segment  of  execution,  either  as  the  "goal"  or  for  changing 
the  current  state.  A  SD  has  4  fields:  pre.-,  mod:,  env:,  and  post:.  When  a  SD  Is  used  to 
Open  a  proof,  then  the  pre:  Is  added  to  the  current  state  and  the  post:  becomes  the 
goal;  when  It  Is  being  "applied",  then  the  pre:  must  be  true  In  the  current  state,  and  the 
effect  of  the  SD  Is  removing  from  the  current  state  everything  that  depends  on  mod: 
and  adding  post:.  A  MAPPING  has  three  fields:  from.-,  to.-,  and  map.  When  a  mapping  Is 
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((MAIN  (.MPC)-16) 

(XFETCH  (.MPO-8)  | 

(FLOOP  (.MPO-ll)  | 

(EXEC  (.MPCI-13  (.MA0)«(USSUB  .R3  il  0) ) )  j 


((Covering  MEM  «ST0RE  16  16») 

(Covering  PC  <<R2  12>>) 

(Covering  ACC  <<R1  16>>) 

(Covering  1R  <<R3  16>>) 

(Covering  MacroPC  <<MicroPC  2>  <MPC  6>>) 

(Covering  HInvReg  «Ml  21>  <MA0  12>  <ALU  16>  <MUX  12>  <MD  16») 
(Covering  TInvReg  <<NInvReg  22>> ) ) 


Figure  0.  Mapping  between  TARGET  and  HOST 
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(MAPPING  (from!  I.MPU-11 

(SO  (pre:) 

(mod:  M i croPC  MI ) 

(env!  MicroPC) 

(post!  W1I - (DOT  (UORDS  ROM  .MPC)) 

(TR  ( (5EQ  (USSET  MPC  *) 

(DECODE  *  »  t  *  *) 

(DECODE  *»•••) 
(DECOOE  •••!«) 
(DECODE  *l*t*««* 
t) 

(DECOOE  11111**1 

in 

(REPEAT  I) 

(ProcMark  HOST) 

(to;  (.  MacroPC) -FL00P) 

(map:  (.MEM) -(.STORE) 

( . PC ) - ( . R2 ) 

(.ACC) -(.Rl) 

(.1R)-(.R3))> 

(MAPPING  (from!  (.MacroPC) -EXEC) 

(to!  (.MPC) -13  (.MAD) - (USSUB  .R3  11  0) 

(SD  (pre:) 

(mod:  MicroPC  MI) 

(env:  MicroPC) 

(post;  #MI-(D0T  (UORDS  RDM  .MPC)) 

(TR  ( (SEQ  (USSET  MPC  I) 

(DECODE  ••*«*) 

(DECODE  ••III) 

(DECODE  lit**) 

(DECODE  •••!••*•*) 
(DECOOE  «•****§•*)) 
(REPEAT  ») 

(ProcMark  HOST) 


(map!  (.STORE) -(.MEM) 
(.R2)-(.PC) 
(.Rl)-(.ACC) 
(,R3) -(. IR) ) ) 


Figure  7.  Two  of  the  MAPPING  records 
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"applied",  Its  from:  must  be  true  In  the  curiont  state,  and  the  effect  of  the  mapping  Is 
adding  to.  and  map.  to  the  current  state 

Flqure  8  shows  an  outline  of  the  batch  of  commands  that  drives  the  proof  In  the  second 
phase  The  first  Open  and  NewDecomposiilnn  declate  the  memories  and  registers  In  the 
HOST  machine.  The  pre.-  of  the  second  Open  Includes  the  microcode  and  the  mapping 
between  the  TARGET  and  the  HOST.  The  post:  of  the  same  command  Includes  the  set  of 
SDs  that  describes  the  TARGET  machine.  Executing  this  command  adds  the  microcode 
and  mapping  to  the  current  state  and  makes  the  TARGET  the  "goal".  A  sequence  of 
seven  NewComposItlon  commands  declares  the  memories  and  registers  In  the  TARGET 
machine  and  their  relation  to  the  places  In  the  HOST.  The  command  SymSimulatB  performs 
the  symbolic  simulation  according  to  a  heuristic  that  we  have  developed. 

The  SymSImulate  command  executes  a  heuristic  that  drives  the  symbolic  simulation.  For 
each  SD  In  the  "goal"  do  the  following:  open  the  SD;  apply  a  mapping  from  the  TARGET  to 
the  HOST;  symbolically  execute  (l.e.,  keep  applying  SDs)  until  the  state  can  be  mapped 
back  to  the  TARGET;  apply  the  mapping  to  the  TARGET;  close  the  SD.  Finally  close  the 
whole  "goal". 

The  combined  effect  of  the  two  phases  of  the  proof  Is  the  generation  of  a  set  of  SDs 
from  the  TARGET  using  symbolic  execution  of  the  TARGET  and  proving  these  SDs  by 
using  symbolic  execution  of  the  HOST  and  microcode.  The  rest  of  the  effort  Is  setting 
up  the  right  relations  among  the  registers  and  memories  and  between  the  HOST  and 
TARGET  to  assure  Integrity  of  the  proof.  Note  that  the  only  Input  needed  Is  the  ISPS 
description  of  the  TARGET,  HOST,  and  ROM  and  the  concise  representation  of  the 
mapping  between  the  machines.  The  rest  is  done  automatically. 

THE  FTSC 

The  FTSC  was  chosen  as  the  real  example  on  which  to  try  out  the  microcode  verification 
system  because  It  Is  a  general-purpose  computer  with  enough  features  to  thoroughly 
test  the  system;  In  addition,  It  Is  still  In  the  development  stage,  so  that  successful 
verification  or  discovery  of  bugs  would  Influence  the  final  version. 
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( (Open  (varsi  MlcroPC  EXP  MO  MUX  ALU  MAO  R3  R2  R1  MI  MPC  STORE  ROM  UNDEFINED 
CLKtOC*  LABlOC*  ASSL0C4  ARRLOCS) 

(SO  (prat  (Covering  OMEGA 

<<M I croPC  1>  <EXP  44Q>  <MD  1G>  <MUX  12> 

<ALU  16>  <MAD  12>  <R3  16>  <R2  12>  <R1  16» 

<M!  21 >  <MPC  6>  <STORE  1G  100B1Q> 

<ROM  21  1 00Q>  < UNDER ! MED  44Q>  <CLKLOC»  44Q> 
<LABL0C4  44Q>  <ASSL0C&  44Q>  <ARRL0C«  44Q>>)) 

(modi  OMEGA) 

(envl ) 

(posti ) ) ) 

(NeuOecompos i  1 1  on  (Cover i ng  OMEGA 

<<Mi croPC  1>  <EXP  44Q>  <M0  1G>  <MUX  12> 

<ALU  1G>  <MA0  12>  <R3  1G>  <R2  12>  <R1  1G> 

<M!  21  >  <f1PC  G>  <ST0RE  1G  10001Q> 

<R0f1  21  100Q>  <UNDEFINED  44Q>  <CLKLOC«  44Q> 
<LABL0C &  44Q>  <ASSL0C&  44Q>  <ARRLOC«  44Q>>)) 
(Open  (varsi  MlcroPC  EXP  IR  ACC  PC  MEM  UNDEFINED  CLKLOCA  LABLOCS  ASSLOCA 
ARRLOCA) 

(SO  (prei  (DOT  (UOROS  ROM  0))-IOCONST  201410Q  21) 

....  (((  Specification  of  microcode  ))l 

(MAPPING  (from:  (.MacroPC) -MAIN) 

(to:  (.MPCU16 
(SD  (pre:) 

(mod:  M i croPC  MI) 

(env:  MicroPC) 

(post:  «MI-(D0T  (UOROS  ROM  .MPC)) 

(TR  ( (SEQ  (USSET  MPC  ») 

(DECODE  »••**) 

(DECODE  •»*»•) 

(DECODE  «•*»•) 

(DECODE  I  i  III  I  I  t  II 
(DECDOE  I  •  I  I  I  I  I  •  ID 
(REPEAT  I) 

(ProcMark  HOST) 

(map:  (.STORE) -(.MEM) 

(.R2)-(.PC) 

(.Rl)-(.ACC) 

( . R3 ) - ( . IR))) 

....  (((All  mapp I nge  1 1 1 


Figure  8.  Outline  of  the  command  batch 
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(mod: ) 

(env: ) 

(post:  (SO  (pre:  (.MacroPC) =MAIN) 

(mod:  TlnvReo  MacroPC  PC) 

( env : ) 

(post:  tfMacrcPC.XFETCH  0PC-1 (12) )) 

••••  I)1  State  Del ^a  representation  of  TARGET  1)1 

(NeuComposi t ion  (Covering  MEM  «ST0RE  16  1S»)  ) 

(NeuCompos  i  t i on  (Covering  PC  <<R2  12:>)) 

(NeuComposi t i on  (Covering  ACC  <<R)  1 E> > ) ) 

(NeuCompos i t i on  (Covering  1R  <<R3  16> > ) ) 

(NeuComposi t ion  (Covering  MacroPC  <<MicroDC  2>  <MPC  6>>)) 

(NeuCompos i t  i  on  (Covering  HlnvReg 

<<MI  21  >  <MAD  12>  <ALU  1G>  <riUX  12>  <f1D  1G») ) 
(NeuCompos  i  t  i  on  (Covering  TInvReg  <<HI nvReg  22>>) ) 

(SymS i mu  I  ate) ) 
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Some  of  the  characteristics  of  the  FTSC  (as  of  May  1979)  are: 

“  112  Instructions,  Including  Integer,  floating  point,  and  vector  operations 

-  data  formats.-  fixed  point  (32-blt,  two's  complement  Integer)  and  floating 
point  (24-blt,  two's  complement  mantissa;  8-blt,  two’s  complement 
exponent) 

-  9  address  modes 

'  8  general-purpose  registers  (that  serve  as  accumulators,  Index  registers, 

or  address  pointers)  and  8  working  registers 

-  1 0  Interrupt  levels 

-  81K  of  addressable  program  memory 

The  first  step  In  the  verification  process  Is  writing  the  formal  host  and  target  machine 
descriptions  In  ISPS.  Ideally,  the  designer  of  the  machine  would  write  the  formal 
description  along  with  the  Informal  description  ("user's  manual").  In  lieu  of  this,  the 
writer  of  the  formal  descriptions  must  submit  them  to  the  designer  for  "description 
verification"  (that  this  Is  really  the  machine  informally  described  In  the  manual)  before 
proceeding  with  the  proof,  fn  addition,  the  writer  of  the  formal  descriptions  may  discover 
"bugs"  (Inconsistencies  or  Incompleteness)  In  the  user  manual. 

As  explained  earlier,  we  consider  the  total  problem  of  microcode  verification  as 
consisting  of  two  parts:  the  proof  that  the  host  machine  with  Its  microcode  Implements 
the  target  machine  (as  described  In  a  language  containing  only  those  operations 
available  to  the  host)  and  the  proof  that  the  target  machine,  Instruction  by  Instruction, 
satisfies  some  higher  level  specification.  For  example,  the  target  machine  description  of 
the  Integer  multiply  and  divide  Instructions,  and  all  floating  point  Instructions,  would  most 
likely  consist  of  an  algorithm  using  the  host  machines  operations  of  shifting,  testing, 
adding,  XORlng,  etc.  The  higher  level  specification  would  be  that  these  Instructions  do 
In  fact  find  the  product,  quotient,  etc.  to  a  given  precision.  The  Instruction  definitions 
given  In  the  user  manual,  which  are  largely  English,  are  most  likely  those  Instructions 
needing  this  second  level  of  proof. 
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All  of  our  work  to  date  on  the  verification  of  the  FTSC  has  been  concerned  with  the  step 
from  the  target  to  the  higher  specification.  This  seemed  a  wise  choice,  since  we  knew 
that  at  the  start  of  our  project  the  FISC  host  macnlne  design  was  not  finalized,  although 
the  target  machine  would  remain  morn  or  less  the  same.  In  addition,  many  aspects  of 
the  system  had  to  be  developed  before  a  truly  large  example  could  be  attacked. 

The  particular  Instruction  chosen  was  square  root.  Square  root  was  chosen  because  of 
the  relative  compactness  of  Its  algorithmic  description  In  the  target  machine,  and  the 
wide  difference  between  the  algorithm  and  Its  higher  specification.  Although  the 
second-level  verification  has  nothing  to  do  with  the  microcode  or  the  host  machine,  one 
characteristic  making  It  less  than  general  program  verification  Is  that  the  data  types 
used  In  the  target  and  higher  level  descriptions  are  usually  restricted  to  be  bltstrlngs 
and  Integers  In  the  target,  and  values  of  bitstrings  und  reals  In  the  higher  level.  Thus 
we  used  the  square  root  Instruction  as  a  testing  gro1  id  for  developing  the  automatic 
simplification  of  expressions  In  these  data  types. 

The  status  of  our  work  on  the  square  root  algorithm  Is  that  the  simplifier  Is  able  to 
handle  automatically  all  the  derivations  needed  to  complete  the  proof  of  correctness. 
Smoothing  the  user  Interface  and  gracefully  setting  up  the  Induction  needed  for  the  loop 
remain  to  be  done. 

It  Is  hoped  that  many  of  the  special  simplfication  rules  adopted  In  proving  the  square 
root  will  also  be  useful  In  the  other  proofs  of  higher  level  correctness. 

Square  Root  Proof 

In  this  section  we  give  the  ISPS  version  of  the  algorithm  that  constitutes  the  FTSC 
target  machine  description  of  the  floating  point  square  root  Instruction  (SRTF).  See 
Figure  9.  This  description  of  the  algorithm  was  written  on  the  basis  of  the  microcode 
flowchart,  which  Is  derived  directly  from  the  host  description  and  the  microcode.  Then 
we  show  the  derivations  the  simplifier  Is  able  to  accomplish  automatically  In  proving  that 
SRTF  finds  the  square  root  to  within  a  certain  accuracy. 
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BEGIN 

DECODE  AI10DE->  (U0<-Ul«-GPXRA,U0*Ul<-f1O)  NEXT 

IF  U0  LSS  0->  (0VFF*-1  NEXT  LEAVE  SRTF)  NEXT 

IF  U0<31:8>  EQL  0-> (GPXRB-"80  NEXT  LEAVE  SRTF)  NEXT 

U0<31 : 8><-U0<31 :8>  SL0  1  NEXT 

U0<7t  0>*-0  NEXT 

OECODE  Ul<0>-> 

BEGIN 

0t-(GPXRB-U0<31s30>  NEXT 
U0-U0  SL0  2  NEXT 
Ul<31 :8>-B  NEXT 


U1  <7: 0><-Ul <7>®U1  <7 : 1  >  ), 

It « (GPXRB*-U8<31>  NEXT 
U8*-U0  SL0  1  NEXT 
Ui <31 : 8>*-0  NEXT 
EXPOUT*-Ul<7>aUl<7: 0>  +  1  NEXT 
Ul  <7: 0>*-EXPDUT <7j  0>  NEXT 
Ul  <7: 0>*-Ul  <7>aUl  <7: 1  >  NEXT 
IF  EXPOUT <8>  XOR  EXP0UT<7>->U1<7: 0>.-#100  ) 


NEXT 

SUM-GPXRB-1  NEXT 
GPXRB*-SUM<29: 0>eU0<31 : 30>  NEXT 
COUNTERS  NEXT 
SLOOP i ■ 

REPEAT 

BEGIN 

COUNTER-COUNTER+1  NEXT 
U0<31:8>4J0<31:8>  5L0  2  NEXT 
DECODE  SUM<31>-> 

BEGIN 

0:-  (Ul <31 : 8>*-2*Ul < 31 : 8>  +  1  NEXT 

IF  COUNTER  EQL  23-> (LEAVE  SLOOP)  NEXT 
U2-4*U1<31:8>  +  1  NEXT 

SUM-GPXRB-U2  NEXT 
GPXRB-SUM<29: 0>aU0<31 : 30> ) , 

It-  (Ul <31 : 8>-2*Ul <31 : 8>  NEXT 

IF  COUNTER  EQL  23->  (LEAVE  SLOOP)  NEXT 
U2<-4ivUl <31 :  8>  +  3  NEXT 
SUM-GPXRB+U2  NEXT 
GPXRB-SUf1<29:0>#U0<31:30>) 

END 

END 

NEXT 

GPXRB-U1 

END 


Figure  9.  ISPS  description  of  the  square  root  algorithm 
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Let  us  "talk  through"  the  algorithm  now:  The  first  line  decides  If  the  Input  Is  to  be  from 
register  GPXRA  or  register  MD.  If  the  Input  Is  negative,  the  algorithm  is  terminated  with 
overflow  flag  set.  If  the  Input  Is  0,  the  algorithm  Is  terminated  with  output  register 
GPXRB  set  to  the  floating  representation  of  0.  From  here  on  the  algorithm  splits  Into  two 
parts:  the  calculation  of  the  new  exponent  and  the  calculation  of  the  new  mantissa.  The 
exponent  calculation  splits  depending  on  whether  It  Is  even  or  odd.  If  the  old  value  Is 
even,  the  new  exponent  Is  half  the  old  value.  If  the  old  value  Is  odd,  It  is  made  even  by 
adding  1  and  shifting  the  mantissa  accordingly  (in  the  even  case  the  mantissa  Is  shifted 
two  bits;  In  the  odd  case,  only  one  bit).  Now  the  new  value  Is  half  the  old  value  (with  a 
check  for  exponent  overflow  thrown  In).  The  mantissa  Is  now  calculated  by  a  variation 
of  the  longhand  high  school  square  root  algorithm.  The  mantissa  Is  shifted  two  bits  at  a 
time  through  the  loop  23  times.  The  loop  has  two  branches  according  to  the  sign  of  the 
"remainder,"  the  register  SUM. 

The  theorem  which  expresses  the  correctness  of  SRTF  Is 

Iheorem:  If  FL(INPUT)rX>0,  then  SRTF  terminates  with  FL(OUTPUT)2  <x  <  FL+(OUTPUT)2. 

If  FL0NPUTX0,  then  SRTF  terminates  with  OVFF-1. 

Explanation  of  notation:  Fl(R)  Is  the  value  of  the  bitstring  R  as  a  floating  point  number  In 
the  FTSC  format:  24  leftmost  bits  coding  two's  complement  fractional  mantissa  and 
rightmost  8  bits  coding  two's  complement  exponent.  INPUT  Is  either  the  register  GPXRA 
or  MD,  depending  on  AMODE.  OUTPUT  Is  the  register  GPXRB.  FL*(R)  Is  floating 
successor  to  Fl(R),  l.e., 

FL*(R)  =  (TCVAL(R<3 1 :8>)+ 1 )  *  2TCVAL(R< 7;0>)’23. 

Letting  MAN(R)  =  TCVAL(R<3 1 :8>)  *  2‘23  and  EXP(R)  =>  TCVAL(R<7.0>),  It  is  sufficient  to 
prove 

(I)  If  EXP(INPUT)=e  Is  even  and  MAN(INPUT)*246=ARG,  then  SRTF  terminates  with 
2*EXP(OUTPUT)=e  and  (MAN(OUTPUT)*223)2  <  ARG  <  (MAN(OUTPUT)*223*1  )2,  and 

(II)  If  EXP(INPUT)*e  Is  odd  and  MAN(INPUT)*245  =  ARG,  then  SRTF  terminates  with 
2*EXP(OUTPUT)=e*1  and  (MAN(OUTPUT)*223)2  S  ARG  <  (MAN(OUTPUT)*223*1  )2. 
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So  the  proof  Is  carried  out  by 

(1)  symbolically  executing  through  the  end  of  the  exponent  calculation  for 
even  and  odd  Input  exponent,  and  proving  the  relevant  parts  of  (I)  and  (II) 
at  that  point  (note  that  OUTPUT  is  assigned  the  contents  of  working 
register  W1  at  the  end  of  SRTF); 

(2)  at  that  point,  for  even  Input  exponent, 

MAN(INPUT)*246  »  USVAL(GPXRB<1:O>0WO<31:1O»*222  •  ARG, 
and  for  odd  exponent, 

MAN(INPUT)*245  *  ARG. 


Thus  to  complete  both  (I)  and  (II)  It  remains  to  show  that 
CLAIM:  TCVAL(OUTPUT<31:8»2  i  ARG  5  TCVAL(OUTPUT<31 :8>+1  )2. 

Here  Is  where  we  use  Induction  to  prove  loop  Invariants  that  lead  to  a  proof  of  the 
CLAIM.  Let  R  denote  the  contents  of  R  after  I  times  through  the  loop,  that  la,  the  last 

contents  before  COUNTER  changes  from  I  to  1+1. 

The  CLAIM  is  proved  from 

SUBCLAIM:  For  1SK23,  USVALtWIjOO^)2  <,  lnt(ARG*22MB)  S  (USVAL(W1(<30:8»+1  )2. 

(The  actual  calculation  with  the  Integer  part  function  Int  Is  done  by  noting  that  If 
X*USVAL(R),  then  lnt(X*2‘*)  *  USVAL(R  SRO  k).) 

The  CLAIM  is  proved  from  the  SUBCLAIM  by  taking  1=23.  The  SUBCLAIM  la  Implied  by  the 
first  three  of  the  following  loop  Invariants  for  1SIS22.  ((HI)  Is  shown  here  for  the  case 
of  even  exponent  only). 

(HI )  (2*USVAL(W1|<30:8»+1  )2  +  TCVAL(SUM()  =  USVAL(a<3O:8>0O(23)  SRO  44-21) 

(H2)  TCVAL(SUM()  i  4*USVAL(W1|<30:8>)  ♦  2 
(H3)  -TCVAL(SUM()  S  4*USVAL(W1(<30:8»  ♦  1 
(H4)  W0(  «us  (a<28:8>90(  1 1 )  SLO  21) 
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(H5)  wi(<31:l*8>  *usO(24-l) 

(H0)  W2(<31:l+2>  =us  0(30-1) 

VH7)  SUM(<29:0>  =us  GPXRB(<31:2> 

(H8)  SUM(  =TC  GPXRB<31:2> 

(H9)  GPXRB(<1:0>  =us  W0(<31:30> 

Thus  we  prove  that  if  (H1)-(H9)  are  true  for  1  < l< 2 1 ,  then  they  are  true  for  1+1. 
Additional  Induction  hypotheses  ((H4)-(H9)  were  found  to  facilitate  the  proof  of 
(HI  )-(H3)).  Then  we  prove  that  If  the  SUBCLAIM  Is  true  for  1SI<22,  then  It  Is  true  for 
1+1.  The  simplifier  automatically  carries  out  these  deductions. 
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5.  CONCLUSIONS 


PLANNED  EXTENSIONS 

The  basic  theoretical  work  for  proofs  of  correctness  of  sequential  microcode  Is 
reasonably  complete,  and  a  preliminary  system  for  carrying  out  proofs  has  been  built  and 
exercised.  Within  the  scope  of  the  present  work,  the  following  extensions  are  planned. 

Proof  Language 

The  system  Is  divided  Into  a  user  Interface  and  a  rigorous  proofchecker.  In  the  present 
Implementation,  the  user  Interface  knows  too  little  about  the  direction  of  the  proof.  In  a 
proof  by  cases,  for  example,  the  separate  cases  are  presented  to  the  proofchecker, 
then  combined.  It  Is  possible  to  declare  the  Intended  result  In  a  superior  proof,  but  no 
use  Is  made  of  this  Information  In  either  the  user  Interface  or  the  kernel. 

We  now  see  that  the  user  Interface  can  Interpret  a  simple  goal-oriented  language.  For  a 
proof  by  cases,  the  user  would  specify  what  lemma  Is  to  be  proven  and  would  specify 
that  the  form  of  the  proof  Is  to  be  by  cases  with  a  given  predicate.  Room  for  specifying 
the  details  of  each  subproof  would  also  exist,  but  the  packaging  of  the  separate  proofs 
would  be  carried  out  by  the  proofchecker.  In  the  present  system,  a  proof  by  cases  now 
looks  like  the  following: 

(Open  P) 

(Open  P  and  C) 

<detalls  of  the  proof  of  the  first  case> 

(Close  P  and  C) 

(Open  P  and  not  C) 

<detalls  of  the  proof  of  the  second  case> 

(Close  P  and  not  C) 

(ComblneCases) 

(Close  P) 

In  many  Instances,  the  proof  of  each  case  may  be  carried  out  automatically.  In  the 
present  system,  a  ProposeMode  statement  Is  required.  We  can  eliminate  the  "obvious" 
proofs  If  we  use  null  lists  where  proof  details  are  permitted.  Combined  with  the 
automatic  setup  and  packaging  of  compound  proofs,  the  proof  above  might  become  the 
following: 
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(Prove  P  (Cases  C  <room  for  details  of  positive  subcase> 

<room  for  details  of  negative  subcase)) 

Similar  savings  would  result  in  proofs  by  Induction.  Some  of  the  savings  are  not 
apparent  from  proof  sketches  like  the  ones  above.  The  lemmas  are  often  quite  lengthy. 
Even  with  the  lemma  suppressed  from  the  Close  command,  the  current  system  requires 
three  copies  of  the  main  lemma,  one  for  the  statement  of  the  lemma  In  the  main  proof, 
and  two  more  for  the  subcase  proofs.  The  compressed  form  requires  only  one 
appearance  of  the  lemma.  In  addition,  the  compressed  form  Is  much  more  readable  and, 
we  hope,  more  writable. 

Editing 

The  present  system  permits  only  limited  editing  of  the  proof.  Using  the  structured  proofs 
Illustrated  above,  It  should  be  possible  to  edit  a  proof  quite  freely  and  have  the  proof 
restarted  from  the  last  point  It  was  changed. 

Efficiency 

The  present  system  Is  fairly  slow.  With  a  little  experimentation,  It  has  become  clear 
that  a  lot  of  time  Is  wasted  In  the  simplifier.  The  simplifier  has  evolved  through  an 
accretion  process,  and  Is  due  for  a  complete  redesign.  We  have  also  studied  Derek 
Oppen's  work  (see,  for  example,  [Nelson  and  Oppen  78]),  and  It  appears  reasonable  to 
use  his  simplifier  for  parts  of  the  system.  His  simplifier  Is  carefully  crafted  and  should 
be  much  faster. 

FUTURE  CONSIDERATIONS 

A  number  of  Ideas  for  logical  next  steps  have  emerged,  though  these  are  beyond  the 
scope  of  the  present  effort. 

Floating  Point  Arithmetic  Specification 

Floating  point  arithmetic  needs  to  be  characterized  precisely.  Notation  to  describe  the 
Intended  precision  of  the  results  and  relationship  between  floating  point  operations  and 
the  corresponding  abstract  operations  on  the  reals  would  materially  reduce  the  size  of 
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the  target  machine  description  and  remove  the  need  for  proving  a  separate  set  of 
constraints. 

Some  of  the  Initial  work  has  been  done  by  Brown  and  others  [Brown  77,  Brown 
78,  WIJngaarden  84,  Kahan  77a,  Kahan  77b]. 

Timing 

Performance  characteristics  play  a  large  part  In  the  design  of  host  machines  end  In  the 
design  of  the  microcode.  However,  to  date  no  work  has  been  done  to  characterize  the 
running  time  of  microcode.  Proofs  of  running  time  limits  should  be  reasonably 
straightforward,  but  work  Is  needed  on  the  specifications. 

Concurrency 

Essentially  no  work  has  been  done  on  correctness  proofs  of  truly  concurrent  microcode. 
The  *present  work  requires  a  sequentlallzed  model  of  the  host  and  target  machines. 
Extensions  to  the  basic  theory  will  be  required  to  model  concurrency. 
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